Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

cohalz
June 07, 2022

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

Hatena Engineer Seminar #20 AWS Renovation 編
https://hatena.connpass.com/event/249039/ の発表資料です

cohalz

June 07, 2022
Tweet

More Decks by cohalz

Other Decks in Programming

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  4. 以前のはてなフォトライフのインフラ
    〜 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

    View full-size slide

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

    View full-size slide

  6. 6
    なぜECSに移行したか

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  22. 22
    まずはDockerfileの作成

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  27. 27
    移行作戦

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  30. 移行の構成図
    30

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  36. 36
    最後にバッチの移行

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  40. 40
    こうして移行完了

    View full-size slide

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

    View full-size slide

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

    View full-size slide