はてなフォトライフをECSに移行した話 / Hatena Engineer Seminar #20

by cohalz

Embed

Start on current slide

Slide 1

Slide 1 text

はてなフォトライフを ECSに移行した話 id:cohalz / @cohalz Hatena Engineer Seminar #20 AWS Renovation 編 1

Slide 2

Slide 2 text

自己紹介 ● id:cohalz (こはる) ● 2018年新卒入社 ● 2019年からはてなブログのチーム 2

Slide 3

Slide 3 text

はてなフォトライフについて ● f.hatena.ne.jp ● 2004年リリース ● 画像アップロードサービス ● はてなブログの編集画面からもアップロードできる 3

Slide 4

Slide 4 text

以前のはてなフォトライフのインフラ〜 2018年 ● オンプレ ● CentOS 5 ● Perl 5.8.8 ● MySQL 4.0 2018 〜 2021年 ● EC2 ● Debian 8 ● Perl 5.28.1 ● Amazon Aurora MySQL 5.6 4

Slide 5

Slide 5 text

今回のアプリケーションのECS移行 2018 〜 2021年 ● EC2 ● Debian 8 ● In Placeデプロイ ○ Capistrano 2 2021年〜 ● ECS on Fargate ● Debian 11 ● Blue/Greenデプロイ ○ CodeDeploy 5

Slide 6

Slide 6 text

6 なぜECSに移行したか

Slide 7

Slide 7 text

なぜECSに移行したか ● トリガー: Let’s Encryptのルート証明書期限切れ ● モチベ１: チームで開発・運用をしやすくする ● モチベ2: ブログのECS移行に向けての知見獲得 7

Slide 8

Slide 8 text

Let’s Encryptのルート証明書期限切れ ● 2021/10以降OpenSSL 1.0.2以下のクライアントからLet’s Encryptを使っているサイトに対してHTTPS接続できなくなる ○ はてなブログやAkamai、FastlyなどのCDNも対象 ○ 構築タイミングでの依存があるかもしれない ■ スケールをはじめ運用できなくなる恐れ 8

Slide 9

Slide 9 text

OSのバージョンを上げられるか ● Debian 9 LTSのEOLが2022/6 ● まだ社内にDebian 10以上のAMIが用意されていなかった ○ 他のチームでコンテナ化が進んでいた ● そもそも社内の古い仕組みを触るのも大変 ○ 属人性が高い 9

Slide 10

Slide 10 text

10 チームで開発・運用をしやすくする

Slide 11

Slide 11 text

開発オーナーの移行 ● 2020年に開発オーナーをブログチームに移行 ○ ブログ起因のタスクの着手順をコントロールしやすくするため ○ 少しずつブログ側で開発・運用していくように ● ブログチームがやりやすい仕組みにしていく ○ オーナー移行により仕組みを変えやすくなった 11

Slide 12

Slide 12 text

オーナー移行によりレイアウトシフト対策の機能もブログチームで開発できた 12

Slide 13

Slide 13 text

ECSにしてチームで開発・運用をしやすくする ● ECSに移行することで ○ チームが理解しやすい仕組みにしていく ■ 世の中で広く使われている技術にする ○ できるだけチーム内で完結できるように ■ 他チームのリソースへの依存を減らす ■ チーム間コミュニケーションコストの削減 13

Slide 14

Slide 14 text

14 ブログのECS移行に向けての知見獲得

Slide 15

Slide 15 text

ブログのECS移行に向けての知見獲得 ● はてなブログ本体だけEC2という状況 ● トラフィックがあるサービスで移行の知見を獲得していく 15

Slide 16

Slide 16 text

スコープ外も伝えておく ● サブシステムの改善はついでに頼まれがち ○ 普段気づかないものを発掘してしまうタイミング ● エラー率やレイテンシの改善は今はやらない ○ 将来的にはやりやすくなるので待って欲しいと伝えた 16

Slide 17

Slide 17 text

17 最初に切り替え方針の決定

Slide 18

Slide 18 text

そもそものプロダクトの難しさ ● 歴史のあるサービスで詳しい人がいない ○ 2018年の移行を担当した人も退職していた ● ブログと同じPerlでも違う構成要素 ○ Apache + mod_perl2 ○ ImageMagick 18

Slide 19

Slide 19 text

19 正直わからないことだらけ

Slide 20

Slide 20 text

20 わからないなりに移行する

Slide 21

Slide 21 text

わからないなりに移行する ● 大きく考えられる手段は二つ ○ 十分に動作確認してメンテ入れて移行する ○ カナリアリリースで少しずつ移行していく ● 今回は後者でPOと方針の合意を取った ○ 問題があった時にも素早く戻しやすい 21

Slide 22

Slide 22 text

22 まずはDockerﬁleの作成

Slide 23

Slide 23 text

Dockerﬁleの作成 ● ベースイメージは motemen/mod_perl ● 各レイヤは社内のmod_perlのDockerﬁleを全部見ていいとこ取り 23

Slide 24

Slide 24 text

GitHub Actionsでビルドしたい ● 社内にある独自パッケージを使っていた ○ GitHub Actionsからアクセスできない ● CIを他に変えるのはあまりしたくない ○ プロダクトごとにCIが変わってしまう ○ 本当に社内にあるパッケージが必要か？ 24

Slide 25

Slide 25 text

社内aptlyを使う必要があるか確認 ● POに仕様を確認し不要と判断 ● EC2側で先にパッケージを変えて動作確認 ● コンテナでも同じパッケージを使って差分をなくす 25

Slide 26

Slide 26 text

26 これで(おそらく)動くイメージができた

Slide 27

Slide 27 text

27 移行作戦

Slide 28

Slide 28 text

アプリケーションの移行 ● ALBの加重ターゲットグループ機能を使う ○ 0.1%刻みでトラフィックの割合を変えられる ○ 反映も一瞬 ● CodeDeployのBlue/Greenデプロイも採用 ○ ローリングデプロイよりもロールバックが高速 ○ ecspressoを利用 28

Slide 29

Slide 29 text

カナリアリリース前に事前に確認 ● ALBのリスナールールを変更して特定のヘッダをつけたらECSに流れるように ○ これで割合に関係なくリクエスト先を選べるように 29

Slide 30

Slide 30 text

移行の構成図 30

Slide 31

Slide 31 text

Mackerelのダッシュボードで確認 ● EC2とECSのターゲットグループを式グラフで同じグラフに載せる ● 割合を50:50にしてエラー率とレイテンシがほぼ一致していることを確認 31

Slide 32

Slide 32 text

いくつか気づいた点 ● 加重ターゲットグループを使っているときは B/Gデプロイができない ○ 一旦加重ルーティングをやめて両方デプロイしその後戻すことが必要 ■ とはいえEC2の台数を減らしてなければ問題にはならない 32

Slide 33

Slide 33 text

いくつか気づいた点2 ● どっちにリクエストが流れているか分かりづらい ○ ヘッダなどで区別をつけられると良い ○ 開発者の検証用ならfaviconを変えるのもオススメ 33

Slide 34

Slide 34 text

ecspressoにフィードバックいくつか欲しかった機能を追加 ● CodeDeployのロールバック ● initでタグもインポート ● desiredCountのdiff ● Terraform Cloud対応 34

Slide 35

Slide 35 text

35 アプリケーションの移行完了

Slide 36

Slide 36 text

36 最後にバッチの移行

Slide 37

Slide 37 text

バッチの移行を考える ● cronで動かしていた ● 一つ一つまだ必要かPOに確認 ● 実行時間は短いものしかなかったのでリクエストベースでの実行に変更していく ○ 最低限APIキー認証だけ含める 37

Slide 38

Slide 38 text

バッチ移行先 ● リクエストを受けるエンドポイントを増やすのも大変でちゃんと動くかわからない ● SQLを実行するバッチは事前に安全なクエリに差し替えて動くのを確認 ○ レスポンスに実行したSQLのクエリと実行時間と成功失敗を含めてデバッグしやすいように 38

Slide 39

Slide 39 text

バッチのトリガー EventBridge + Lambda ● LambdaがHTTPリクエストを送る ● Mackerelに実行時間と成功/失敗をメトリックにして送る ● 他チームで動いているものを真似して再実装 39

Slide 40

Slide 40 text

40 こうして移行完了

Slide 41

Slide 41 text

おわり ● プロジェクト期間は約2ヶ月ほど ○ 大きな問題も発生せず完了 ● この知見を元にはてなブログ本体のECS移行も進行中 41

Slide 42

Slide 42 text

(参考) 2018年に行った移行について ● MySQLをアップデートする話 - Hatena Developer Blog ● Hatena Engineer Seminar #11で「MySQL自前運用やめて Aurora導入する話」した - 角待ちは対空 ● Legacy Meetup Kyotoで「レガシーシステムとインフラオーナーシップ」という発表した - 角待ちは対空 42