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

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

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

Transcript

1. Hatena Engineer Seminar #19 id: AWSアカウントとIaaSの 段階的移行 カクヨムの10年を見据えた技術 インフラ編 2022.03.30 koudenpa
2. • koudenpa ◦ コウデン ◦ 太田浩一 • https://twitter.com/koudenpa • https://koudenpa.hatenablog.com/ • Webアプリケーションエンジニア • SI企業、Webサービス企業などを 経て2018年秋にはてなへ入社 以後カクヨムを担当 id: koudenpa
3. 目次 • 背景・概要 • 段階的移行を追う • 移行ネタ集 • まとめ
4. 背景・概要
5. 移行前構成 • 『はてな』アカウント • IaaS（EC2）
6. 移行後構成 • 『カクヨム』アカウント • マネージドサービス • コンテナ（ECS Fargate） • 『はてな』少し残ってる
7. なにをしたかったか • 継続的な開発運用 • その準備として • 継続的に運用できるインフラへの刷新
8. やったこと・関心ごと • AWSアカウント切り離し • IaaSからの脱却 ◦ マネージド化 ◦ コンテナ化
9. カクヨムの特性 • 典型的なWebアプリケーション • アクセス数は増加傾向 ◦ 超高トラフィックではない ◦ （Twitterなどではない） • 一般的に良いとされる手法に倣えばよい
10. モデルケース • 魔法のiらんど ◦ Hatena Engineer Seminar #14 〜魔法のiらんど編〜 ◦ https://developer.hatenastaff.com/entry/2020/09/04/093000 • チームの担当サービス ◦ カクヨム ◦ 魔法のiらんど • コードベース ◦ カクヨムと魔法のiらんどは同じ ▪ バックエンドの処理のみ ◦ 概ね同様の構成で動作するはず
11. 移行後構成の理由 • モデルケースはあれども • それぞれ理由はある ◦ 魔法のiらんどでそうした理由でもある
12. AWSアカウント切り離し • 前 ◦ はてな全体の共有アカウント・ネットワーク • 後 ◦ カクヨム専用のアカウント・ネットワーク • 理由 ◦ アカウント管理のベストプラクティスに乗る ▪ https://docs.aws.amazon.com/ja_jp/organizations/latest/use rguide/orgs_best-practices.html ◦ 様々な要素の独立 ▪ AWSのレート制限 ▪ 誤操作のリスク
13. マネージド化 • 前 ◦ IaaS（EC2）をChef管理 • 後 ◦ AWSの管理 • 理由 ◦ 管理負荷の低減 ◦ サービスを運用しやすく
14. コンテナ化 • 前 ◦ IaaS（EC2）をChef管理 • 後 ◦ コンテナ環境（ECS Fargate） • 理由 ◦ 一般的なコンテナ運用の利点を得る ◦ 開発から本番まで同様の環境 ◦ 構成を変更しやすく
15. 現行機能を維持 • 何はなくとも大目的を達成することを優先 ◦ AWSアカウント切り離し ◦ マネージド化 ◦ コンテナ化 • 最適化を欲張らない ◦ 簡単なものはやる ▪ 今後最適化する準備まで、など
16. 段階的移行 • カクヨムは成長中 ◦ 未来を見据えた機能追加や状況に応じた改善を止めない • インフラ要素を1つずつ移行 ◦ ビッグバンで一気にではない ◦ サービス影響のリスク・準備のコスト低減 ◦ 機能開発と並行
17. 段階 • 永続化層 ◦ MySQL ◦ Redis ◦ Elasticsearch • アプリケーション ◦ Webアプリケーション ◦ Jobワーカー ◦ Batchサーバー • ミドルウェア ◦ Nginx, Varnish
18. 移行時の対応 • メンテナンス有り ◦ 10分～以上のサービスダウンやロールバック考慮 ◦ 悲観的に見た作業時間をアナウンス ◦ リバースプロキシやCDNでメンテナンスページを応答 • メンテナンス無し ◦ ～数分程度のサービスダウン ◦ ユーザーには一定時間内にサービスにつながらない時間が ある旨をアナウンス ◦ ユーザー影響はダウンしてる時間のみになる • 移行以外でも同様 ◦ マネージドサービスのバージョンアップグレードなど
19. 段階的移行を追う
20. 移行前
21. 01 ネットワーク間接続
22. 01 ネットワーク間接続 • 移行前 ◦ AWSやオンプレミスで構成されたネットワーク ▪ カクヨムはAWSのみ • 移行後 ◦ カクヨム専用のアカウント・VPC • AWS Transit Gateway（TGW）で相互接続 ◦ 段階的移行の準備 ◦ 1部のリソースだけ移動を可能に
23. 02 MySQL移行
24. 02 MySQL移行
25. 02 MySQL移行 • RDS MySQL • 移行前からレプリケーション • 移行実施時は接続先の切り替え ◦ メンテナンス有（安全寄せ）
26. 03 Redis移行
27. 03 Redis移行
28. 03 Redis移行 • ElastiCache Redis • 移行前からレプリケーション • 移行実施時は接続先の切り替え ◦ メンテナンス有（安全寄せ）
29. 04 Elasticsearch移行
30. 04 Elasticsearch移行
31. 04 Elasticsearch移行 • OpenSearch Service ◦ Amazon Elasticsearch Service の後継 • 移行前後にダブルライト • 移行実施時は参照を切り替え ◦ メンテナンスなし
32. 05 Webアプリ移行
33. 05 Webアプリ移行
34. 05 Webアプリ移行 • ECS Fargate • ローカルマシンをコンテナで動かす • 本番同様の開発環境を構成して動作確認 • 本番構築 • 移行はNginxのルーティングを切り替え ◦ メンテナンスなし
35. 06 Nginx移行
36. 06 Nginx移行
37. 06 Nginx移行 • CloudFront、ECS Fagate • 開発環境を構成して検証・動作確認 • 併せて本番環境も構成 • 移行はDNSを切り替え ◦ メンテナンスなし ◦ 切り替えミスで一部ユーザーに影響🙇
38. 07 SSRサーバ追加
39. 07 SSRサーバ追加 • ECS Fargete • React導入の一環としてNext.jsのSSRサーバを追加 • 開発環境を構成して検証・動作確認 • 併せて本番環境も構成 • 適切な時期にリリース ◦ メンテナンスなし
40. 08 Worker/Batch移行
41. 08 Worker/Batch移行
42. 08 Worker/Batch移行 • ECS Fargate • EC2上でのDocker run • 開発環境を構成して検証・動作確認 • 併せて本番環境も構成 • Jobワーカーは並行稼働の後に旧環境停止 • Batchは旧環境停止後に新環境稼働 • ユーザーには見えない出来事 ◦ メンテナンスなし
43. 09 ネットワーク間接続解除
44. 09 ネットワーク間接続解除
45. 09 ネットワーク間接続削除 • 削除！
46. 前
47. 01 ネットワーク間接続
48. 02 MySQL移行
49. 03 Redis移行
50. 04 Elasticsearch移行
51. 05 Webアプリ移行
52. 06 Nginx移行
53. 07 SSRサーバ追加
54. 08 Worker/Batch移行
55. 09 ネットワーク間接続解除
56. 後
57. 移行ネタ集
58. おしながき • やらなかったこと・残課題 ◦ 『はてな』に残っているリソース ◦ CDN活用・キャッシュ最適化 ◦ Batchの実行環境 • SSRサーバへのルーティング • TGWトラフィック • CI/CD変遷 • 他
59. 『はてな』に残っているリソース • 『はてな』少し残ってる • グローバルに一意な名前 • 移行パスはある ◦ がちょっと面倒 • ほとんど変更しない • ので差し当たって残
60. CDN活用・キャッシュ最適化 • CDNの活用は準備まで ◦ CloudFrontとACMでの証明書管理 ◦ 今後『層』の追加なしにカイゼンできるように • Nginx, Varnish ◦ 責務整理・最適化まで手が回らなかった
61. Batchの実行環境 • モデルケース同様の構成 • EC2上のCronで docker run ◦ 既存のスケジュールを使う ◦ コンテナは使う • アカウント切り離しとコンテナ化に注力した結果 • 今後クラウドネイティブ化していきたい部分
62. SSRサーバへのルーティング
63. SSRサーバへのルーティング • SSRは『追加』 • 本番確認、内部の人間だけでしたい • あるURLをReactでレンダリングするか判断したい • そこで「X-Accel」 ◦ https://www.nginx.com/resources/wiki/start/topics/examples/x- accel/
64. X-Accel • Nginxの機能 • Upstreamからの応答ヘッダを見て内部リダイレクト • バックエンドのアプリケーションで判断 ◦ 一般ユーザーにはHTMLをレンダリングして応答 ◦ 管理者ユーザーには X-Accel でSSR結果を応答 • こっそりSSRを確認できた
65. X-Accel なしHTML応答 1 3 2 1. NginxからWebアプリへ 2. WebアプリはHTML応答 3. 素直に応答
66. X-Accel してSSR結果応答 1 4 3 2 5 1. NginxからWebアプリへ 2. WebアプリはX-Accel応答 3. X-AccelならSSRサーバへ 4. SSR！ 5. 最終的な応答
67. TGWトラフィック • ネットワークを超えるトラフィックがどの程度か？ • リソースを移行するごとに減 • なくなった段階でTGWを削除、お役御免
68. TGWトラフィック
69. TGWトラフィック Webアプリケーションの移行 Nginxの移行 Worker/Batchの移行 PV増の様子 ？？？ 永続化層（MySQL）の移行 永続化層（MySQL） レプリケーション中
70. CI/CD変遷 • インフラの移行と並行して見直し
71. おわかりいただけただろうか？
72. おわかりいただけただろうか？
73. CI/CD変遷 • 前 ◦ JenkinsでのCI ◦ 手作業でのCD • 後 ◦ GitHub ActionsでのCI ◦ AWS CodePipelineでのCD • いずれも『主に』
74. Jenkins • 主にCIに活用 • チームで管理しきれていなかった • マネージド化の一環 • 地道にジョブを置き換え ◦ GitHub Actionsのワークフローへ
75. 手作業でのCD • Capistranoをローカルマシンで実行 • デリバリー対象の変化 ◦ ソースコード -> コンテナイメージ • デリバリー先の変化 ◦ EC2 -> ECS Fargate • AWSへはAWSで ◦ CodePipelines（＋CodeBuild, CodeDeploy）
76. 他 • 気になる点があれば ◦ 質疑応答 ▪ この後 ◦ 懇親会 ▪ セミナー後 ◦ はてなへ入社 ▪ https://hatenacorp.jp/recruit/engineer
77. まとめ
78. 移行前構成 • 『はてな』アカウント • IaaS（EC2）
79. 移行後構成 • 『カクヨム』アカウント • マネージドサービス • コンテナ（ECS Fargate） • 『はてな』少し残ってる
80. ポイント • AWSアカウント切り離し ◦ ネットワーク間接続はAWSのTGW経由 • ビックバンでなく1要素ずつ ◦ マネージド化 ◦ コンテナ化 • 機能開発と並行 ◦ 機能リリース ◦ React化向けのSSRサーバ追加 • それぞれ達成
81. 得たもの • マネージド化 ◦ 運用しやすく • コンテナ化 ◦ 変更しやすく
82. 10年を見据えて • 運用しやすく • 変更しやすく • 今後に対応しやすくなったカクヨムにご期待ください
83. つづく