Tweet
Tweet

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 まずはDockerfileの作成

Slide 23

Slide 23 text

Dockerfileの作成 ● ベースイメージは motemen/mod_perl ● 各レイヤは社内のmod_perlのDockerfileを 全部見ていいとこ取り 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