去年の１２月下旬に公開されたEC2→ECSへの移行記事が結構体系的にまとまっていて勉強になります。
EC2、ECS周りは知っておいて損はないのでその辺りを想像含め勝手に色々考えてみました。適当なこと言ってたらごめんなさい🙏
CloudFront
記事の構成図にはいずれもCloudFrontがありませんでした。幾つかのドメインのレスポンスヘッダーを見ても使ってなさそうです。ブログのホスティングサービスならとりあえずCDNと安直に思ってしまったのですが、はてな程の規模だとCloudFrontのコストもすごそうです。昨今の便利なクラウドサービスの台頭で感覚がマヒしてますが、、たしかにCDNだけがキャッシュじゃないですね。
LB
前段がNLB、中にあるLBがALBなのが興味深いです。前段にALBを置いておけば後に拡張しやすくなるので自分なら無難な方を選ぶ気がします。。経緯は分かりませんが先を見据えた上での決断だなと感じます。
あとはALBの採用理由でメトリクスを見れるから、というのは運用視点を持ってないとなかなか出てこないのでなるほどって思いました。ただ、Cloud Mapでも加重ルーティングはできたような覚えがあって、ECSとの親和性も高いのでこっちもなかなか魅力的です。
S3
EC2上のNginxからS3にプロキシで通すパターン、自分はこのやり方で構築したことがないので何か惹かれました。
この構成で良いなと思ったのはNginxのauth_requestを使えばS3のファイルアクセスをアプリ側で制御できることです。記事の説明によるとパブリックな静的ファイルっぽいのではてなブログではあんまり関係ないのかもしれませんが。
あとはNginx -> S3／Webアプリの構成だとローカル環境が作りやすいのが利点ですね。たしかに前述のCloudFront、NLB、ALBの部分に手を入れるとAWS-ローカル環境の差異が大きくなってしまいます。
バッチ
バッチの実行をHTTPで受けるというのがちょっと意外でしたが、ECS上で実現するなら選択肢はあまり多くない気がします。HTTPのエンドポイントの部分は多少なり実装を加えてるはずですが、どのぐらいのボリュームだったのか興味深いです。ツールをGitHubで公開しつつ社内で使う文化もめちゃくちゃ良いですね。
私も直近の仕事でEC2上のバッチ（CRON）周りに手を入れたところでした。自分の場合はCRONをやめてEvent BridgeでLambdaからSystems ManagerのRun CommandでEC2のスクリプトを叩くように変更を行いました。記事の構成とは違って不特定多数のEC2に対し定期的にコマンド実行するという特殊な要件だったため、EC2をタグでフィルターして一覧取得→対象のEC2にシェル実行という流れです。
バッチ周りの設定や構成は把握しづらいことが多いので、こういう工夫した話は大体面白いですね。
その他
コストがgzip導入の前後でどのくらい数字が違うのかめっちゃ気になりましたねー。はてなブログほどの大きい規模だと想像ができないです。あとMySQL(EC2)となっていて当初から自前で運用しているのかなとか。DB周りの話も面白そうです。
最後に
最近 Backyard Hatenaのポッドキャストを聴いたり、開発ブログを目にする機会が増えています。色々学ぶことが多いので紹介させて頂きました。
1/25にはてなエンジニアセミナーが開催されるようなのでこちらも参加したいと思います😎
以上 宣伝でした。いつか後編を書くかも...?
