Hatena Engineer Seminar #20 AWS Renovation 編 https://hatena.connpass.com/event/249039/ の発表資料です
はてなフォトライフをECSに移行した話id:cohalz / @cohalzHatena Engineer Seminar #20AWS Renovation 編1
View Slide
自己紹介● id:cohalz (こはる)● 2018年新卒入社● 2019年からはてなブログのチーム2
はてなフォトライフについて● f.hatena.ne.jp● 2004年リリース● 画像アップロードサービス● はてなブログの編集画面からもアップロードできる3
以前のはてなフォトライフのインフラ〜 2018年● オンプレ● CentOS 5● Perl 5.8.8● MySQL 4.02018 〜 2021年● EC2● Debian 8● Perl 5.28.1● Amazon AuroraMySQL 5.64
今回のアプリケーションのECS移行2018 〜 2021年● EC2● Debian 8● In Placeデプロイ○ Capistrano 22021年 〜● ECS on Fargate● Debian 11● Blue/Greenデプロイ○ CodeDeploy5
6なぜECSに移行したか
なぜECSに移行したか● トリガー: Let’s Encryptのルート証明書期限切れ● モチベ１: チームで開発・運用をしやすくする● モチベ2: ブログのECS移行に向けての知見獲得7
Let’s Encryptのルート証明書期限切れ● 2021/10以降OpenSSL 1.0.2以下のクライアントからLet’s Encryptを使っているサイトに対してHTTPS接続できなくなる○ はてなブログやAkamai、FastlyなどのCDNも対象○ 構築タイミングでの依存があるかもしれない■ スケールをはじめ運用できなくなる恐れ8
OSのバージョンを上げられるか● Debian 9 LTSのEOLが2022/6● まだ社内にDebian 10以上のAMIが用意されていなかった○ 他のチームでコンテナ化が進んでいた● そもそも社内の古い仕組みを触るのも大変○ 属人性が高い9
10チームで開発・運用をしやすくする
開発オーナーの移行● 2020年に開発オーナーをブログチームに移行○ ブログ起因のタスクの着手順をコントロールしやすくするため○ 少しずつブログ側で開発・運用していくように● ブログチームがやりやすい仕組みにしていく○ オーナー移行により仕組みを変えやすくなった11
オーナー移行によりレイアウトシフト対策の機能もブログチームで開発できた12
ECSにしてチームで開発・運用をしやすくする● ECSに移行することで○ チームが理解しやすい仕組みにしていく■ 世の中で広く使われている技術にする○ できるだけチーム内で完結できるように■ 他チームのリソースへの依存を減らす■ チーム間コミュニケーションコストの削減13
14ブログのECS移行に向けての知見獲得
ブログのECS移行に向けての知見獲得● はてなブログ本体だけEC2という状況● トラフィックがあるサービスで移行の知見を獲得していく15
スコープ外も伝えておく● サブシステムの改善はついでに頼まれがち○ 普段気づかないものを発掘してしまうタイミング● エラー率やレイテンシの改善は今はやらない○ 将来的にはやりやすくなるので待って欲しいと伝えた16
17最初に切り替え方針の決定
そもそものプロダクトの難しさ● 歴史のあるサービスで詳しい人がいない○ 2018年の移行を担当した人も退職していた● ブログと同じPerlでも違う構成要素○ Apache + mod_perl2○ ImageMagick18
19正直わからないことだらけ
20わからないなりに移行する
わからないなりに移行する● 大きく考えられる手段は二つ○ 十分に動作確認してメンテ入れて移行する○ カナリアリリースで少しずつ移行していく● 今回は後者でPOと方針の合意を取った○ 問題があった時にも素早く戻しやすい21
22まずはDockerfileの作成
Dockerfileの作成● ベースイメージは motemen/mod_perl● 各レイヤは社内のmod_perlのDockerfileを全部見ていいとこ取り23
GitHub Actionsでビルドしたい● 社内にある独自パッケージを使っていた○ GitHub Actionsからアクセスできない● CIを他に変えるのはあまりしたくない○ プロダクトごとにCIが変わってしまう○ 本当に社内にあるパッケージが必要か？24
社内aptlyを使う必要があるか確認● POに仕様を確認し不要と判断● EC2側で先にパッケージを変えて動作確認● コンテナでも同じパッケージを使って差分をなくす25
26これで(おそらく)動くイメージができた
27移行作戦
アプリケーションの移行● ALBの加重ターゲットグループ機能を使う○ 0.1%刻みでトラフィックの割合を変えられる○ 反映も一瞬● CodeDeployのBlue/Greenデプロイも採用○ ローリングデプロイよりもロールバックが高速○ ecspressoを利用28
カナリアリリース前に事前に確認● ALBのリスナールールを変更して特定のヘッダをつけたらECSに流れるように○ これで割合に関係なくリクエスト先を選べるように29
移行の構成図30
Mackerelのダッシュボードで確認● EC2とECSのターゲットグループを式グラフで同じグラフに載せる● 割合を50:50にしてエラー率とレイテンシがほぼ一致していることを確認31
いくつか気づいた点● 加重ターゲットグループを使っているときはB/Gデプロイができない○ 一旦加重ルーティングをやめて両方デプロイしその後戻すことが必要■ とはいえEC2の台数を減らしてなければ問題にはならない32
いくつか気づいた点2● どっちにリクエストが流れているか分かりづらい○ ヘッダなどで区別をつけられると良い○ 開発者の検証用ならfaviconを変えるのもオススメ33
ecspressoにフィードバックいくつか欲しかった機能を追加● CodeDeployのロールバック● initでタグもインポート● desiredCountのdiff● Terraform Cloud対応34
35アプリケーションの移行完了
36最後にバッチの移行
バッチの移行を考える● cronで動かしていた● 一つ一つまだ必要かPOに確認● 実行時間は短いものしかなかったのでリクエストベースでの実行に変更していく○ 最低限APIキー認証だけ含める37
バッチ移行先● リクエストを受けるエンドポイントを増やすのも大変でちゃんと動くかわからない● SQLを実行するバッチは事前に安全なクエリに差し替えて動くのを確認○ レスポンスに実行したSQLのクエリと実行時間と成功失敗を含めてデバッグしやすいように38
バッチのトリガーEventBridge + Lambda● LambdaがHTTPリクエストを送る● Mackerelに実行時間と成功/失敗をメトリックにして送る● 他チームで動いているものを真似して再実装39
40こうして移行完了
おわり● プロジェクト期間は約2ヶ月ほど○ 大きな問題も発生せず完了● この知見を元にはてなブログ本体のECS移行も進行中41
(参考) 2018年に行った移行について● MySQLをアップデートする話 - Hatena Developer Blog● Hatena Engineer Seminar #11で「MySQL自前運用やめてAurora導入する話」した - 角待ちは対空● Legacy Meetup Kyotoで「レガシーシステムとインフラオーナーシップ 」という発表した - 角待ちは対空42
cohalz
ryu_hu03
maguroalternative
katsyoshi
twada
punchdrunker
yumakann
ffjlabo
track3jyo
gishi_yama
soutaro
syossan27
munetoshi
danielanewman
nonsquared
csswizardry
afnizarnur
eitanlees
jennybc
trallard
chriscoyier
jeffersonlam
akosma
aleyda
shpigford