Welcome to eazy code

この記事はヤプリ&フラー 合同アドベントカレンダー Advent Calendar 2025の 18 日目の記事です。 このブログサイトのインフラを EC2 + WordPress から GitHub + Amplify Hosting に再設計した経験について共有します。（いまこの記事を表示しているこのブログが、この記事紹介する構成で動いています。） この記事では、なぜインフラを見直したのか、なぜこの構成を選んだのか、実際のアーキテクチャと運用体験について解説します。 なぜインフラを見直したのか 以前、別のテックブログを運用していたのですが、その際は EC2 上で WordPress を用いて運用していたのですが、以下のような課題がありました。 その結果、ブログの更新頻度が低くなってしまい、結果として運用をやめてしまいました。 メンテナンス作業の負担: WordPress やプラグインの定期的なアップデート、セキュリティパッチの適用が必要で、手動作業である以上つい後回しになってしまう 記事執筆の手間: 管理画面へのログインが面倒で、結局 Zenn など他のプラットフォームで記事を書くようになっていた コスト: 個人ブログのアクセス量に対して、EC2 の継続的なコストが割高だった 一番は管理画面からログインしてから記事を書く必要があるのが面倒で、記事を書くハードルが高くなってしまっていたことです。 Zenn では markdown で記事を書けるので、同じように記事を書けるような仕組みを構築すれば、ハードルが下がるのではないかと考えました。（あと単純に markdown で記事を管理できるようにするには、どうしたらいいのかという技術的な興味もありました。） GitHub × Hugo × Amplify の選定理由 インフラを見直すにあたり、実現したいことは以下でした。 markdown で記事を書きたい github で記事を管理したい できれば自動でデプロイしたい いくつかの選択を検討したのですが、最終的に GitHub × Hugo × Amplify の組み合わせを選定することになりました。 Hugo とは Hugo は、Go 言語で書かれた静的サイトジェネレータ（SSG: Static Site Generator）です。マークダウンファイルから HTML ファイルを生成し、静的なウェブサイトを構築するツールです。 ...

はじめに 先日とある API 関連の本を読んでいたときに、レートリミットについて触れている箇所がありました。 それを読んでいて、ふと「自分でレートリミットの実装をしたことないなぁ」「Go でどうやってレートリミットを実装するんだろう」と思ったので、この記事では golang.org/x/time/rate を使ってレートリミットを実装してみたことをまとめます。 システムの安定性を保つためには、外部からのリクエスト数を適切に制御することが重要です。この記事が、Go で API サーバーなどを開発している人の参考になれば幸いです。 golang.org/x/time/rate とは golang.org/x/time/rate は、準標準パッケージの一つで、トークンバケット (Token Bucket) と呼ばれるアルゴリズムに基づいたレートリミッターを提供します。 なぜレートリミットが必要か？ 外部に公開している API サーバーなどのシステムを運用する上で、以下のような理由からレートリミットは不可欠です。 過負荷からの保護: 特定のユーザーやクライアントからの大量リクエストによるサーバーダウンを防ぎます。 公平なリソース分配: 全てのユーザーが安定してサービスを利用できるよう、リソースを公平に分配します。 悪意のある攻撃の緩和: ブルートフォース攻撃や DDoS 攻撃のような、短時間に大量のリクエストを送る攻撃を緩和します。 トークンバケットアルゴリズムの仕組み rateパッケージを理解するために、トークンバケットの概念について説明します。これは「トークンが入ったバケツ」に例えることができます。 バケツ (Bucket): リクエストを処理する権利である「トークン」を貯めておく場所です。このバケツの容量が burst (バースト) 量にあたります。 トークンの補充 (Refill): バケツには、一定のペースで新しいトークンが補充されます。この補充される速さが rate (レート) です。 リクエストの処理 (Consume): リクエストが 1 つ来るたびに、バケツからトークンを 1 つ消費します。 もしリクエストが来たときにバケツにトークンがあれば、即座にリクエストは許可されます。しかし、トークンが空っぽの場合、新しいトークンが補充されるまで待つか、リクエストを諦める（拒否する）しかありません。 この仕組みの優れた点は、平均レートを制御しつつ、一時的なリクエストの集中（バースト）にも対応できることです。 rate.Limit (レート): 1 秒あたりにバケツに補充されるトークンの数です。これにより、長期的に見た場合の平均リクエストレートが決定されます。例えば rate.Limit(10) であれば、1 秒間に 10 個のペースでトークンが補充されます。 burst (バースト): バケツの最大容量です。普段リクエストが少なくトークンが貯まっている状態であれば、最大でこの burst 数まで、レートを超えた連続リクエストを即座に処理できます。これにより、アプリケーションの応答性を損なわずに、突発的なトラフィックをさばくことが可能になります。 インストール まずはパッケージをインストールします。 ...