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

カクヨムの10年を見据えた技術──インフラ編──AWSアカウントとIaaSの段階的移行── H...

koudenpa
March 30, 2022

カクヨムの10年を見据えた技術──インフラ編──AWSアカウントとIaaSの段階的移行── Hatena Engineer Seminar #19

Hatena Engineer Seminar #19 カクヨム編 の資料です。
https://hatena.connpass.com/event/241412/

カクヨムはAWSのはてなのサービスで共有のアカウントで、EC2を活用して運用されてきました。これを段階的にカクヨム固有のアカウントに切り出し、マネージドサービスやコンテナ技術を活用するように変更して運用性を高めました。その動機や具体的な手順をお話します。

koudenpa

March 30, 2022
Tweet

More Decks by koudenpa

Other Decks in Programming

Transcript

  1. • koudenpa ◦ コウデン ◦ 太田浩一 • https://twitter.com/koudenpa • https://koudenpa.hatenablog.com/

    • Webアプリケーションエンジニア • SI企業、Webサービス企業などを 経て2018年秋にはてなへ入社 以後カクヨムを担当 id: koudenpa
  2. モデルケース • 魔法のiらんど ◦ Hatena Engineer Seminar #14 〜魔法のiらんど編〜 ◦

    https://developer.hatenastaff.com/entry/2020/09/04/093000 • チームの担当サービス ◦ カクヨム ◦ 魔法のiらんど • コードベース ◦ カクヨムと魔法のiらんどは同じ ▪ バックエンドの処理のみ ◦ 概ね同様の構成で動作するはず
  3. AWSアカウント切り離し • 前 ◦ はてな全体の共有アカウント・ネットワーク • 後 ◦ カクヨム専用のアカウント・ネットワーク •

    理由 ◦ アカウント管理のベストプラクティスに乗る ▪ https://docs.aws.amazon.com/ja_jp/organizations/latest/use rguide/orgs_best-practices.html ◦ 様々な要素の独立 ▪ AWSのレート制限 ▪ 誤操作のリスク
  4. マネージド化 • 前 ◦ IaaS(EC2)をChef管理 • 後 ◦ AWSの管理 •

    理由 ◦ 管理負荷の低減 ◦ サービスを運用しやすく
  5. コンテナ化 • 前 ◦ IaaS(EC2)をChef管理 • 後 ◦ コンテナ環境(ECS Fargate)

    • 理由 ◦ 一般的なコンテナ運用の利点を得る ◦ 開発から本番まで同様の環境 ◦ 構成を変更しやすく
  6. 段階 • 永続化層 ◦ MySQL ◦ Redis ◦ Elasticsearch •

    アプリケーション ◦ Webアプリケーション ◦ Jobワーカー ◦ Batchサーバー • ミドルウェア ◦ Nginx, Varnish
  7. 移行時の対応 • メンテナンス有り ◦ 10分~以上のサービスダウンやロールバック考慮 ◦ 悲観的に見た作業時間をアナウンス ◦ リバースプロキシやCDNでメンテナンスページを応答 •

    メンテナンス無し ◦ ~数分程度のサービスダウン ◦ ユーザーには一定時間内にサービスにつながらない時間が ある旨をアナウンス ◦ ユーザー影響はダウンしてる時間のみになる • 移行以外でも同様 ◦ マネージドサービスのバージョンアップグレードなど
  8. 01 ネットワーク間接続 • 移行前 ◦ AWSやオンプレミスで構成されたネットワーク ▪ カクヨムはAWSのみ • 移行後

    ◦ カクヨム専用のアカウント・VPC • AWS Transit Gateway(TGW)で相互接続 ◦ 段階的移行の準備 ◦ 1部のリソースだけ移動を可能に
  9. 04 Elasticsearch移行 • OpenSearch Service ◦ Amazon Elasticsearch Service の後継

    • 移行前後にダブルライト • 移行実施時は参照を切り替え ◦ メンテナンスなし
  10. 06 Nginx移行 • CloudFront、ECS Fagate • 開発環境を構成して検証・動作確認 • 併せて本番環境も構成 •

    移行はDNSを切り替え ◦ メンテナンスなし ◦ 切り替えミスで一部ユーザーに影響🙇
  11. 08 Worker/Batch移行 • ECS Fargate • EC2上でのDocker run • 開発環境を構成して検証・動作確認

    • 併せて本番環境も構成 • Jobワーカーは並行稼働の後に旧環境停止 • Batchは旧環境停止後に新環境稼働 • ユーザーには見えない出来事 ◦ メンテナンスなし
  12. Batchの実行環境 • モデルケース同様の構成 • EC2上のCronで docker run ◦ 既存のスケジュールを使う ◦

    コンテナは使う • アカウント切り離しとコンテナ化に注力した結果 • 今後クラウドネイティブ化していきたい部分
  13. X-Accel してSSR結果応答 1 4 3 2 5 1. NginxからWebアプリへ 2.

    WebアプリはX-Accel応答 3. X-AccelならSSRサーバへ 4. SSR! 5. 最終的な応答
  14. CI/CD変遷 • 前 ◦ JenkinsでのCI ◦ 手作業でのCD • 後 ◦

    GitHub ActionsでのCI ◦ AWS CodePipelineでのCD • いずれも『主に』
  15. 手作業でのCD • Capistranoをローカルマシンで実行 • デリバリー対象の変化 ◦ ソースコード -> コンテナイメージ •

    デリバリー先の変化 ◦ EC2 -> ECS Fargate • AWSへはAWSで ◦ CodePipelines(+CodeBuild, CodeDeploy)
  16. 他 • 気になる点があれば ◦ 質疑応答 ▪ この後 ◦ 懇親会 ▪

    セミナー後 ◦ はてなへ入社 ▪ https://hatenacorp.jp/recruit/engineer
  17. ポイント • AWSアカウント切り離し ◦ ネットワーク間接続はAWSのTGW経由 • ビックバンでなく1要素ずつ ◦ マネージド化 ◦

    コンテナ化 • 機能開発と並行 ◦ 機能リリース ◦ React化向けのSSRサーバ追加 • それぞれ達成