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