$30 off During Our Annual Pro Sale. View Details »

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

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. Hatena Engineer Seminar #19
    id:
    AWSアカウントとIaaSの
    段階的移行
    カクヨムの10年を見据えた技術 インフラ編
    2022.03.30
    koudenpa

    View Slide

  2. ● koudenpa
    ○ コウデン
    ○ 太田浩一
    ● https://twitter.com/koudenpa
    ● https://koudenpa.hatenablog.com/
    ● Webアプリケーションエンジニア
    ● SI企業、Webサービス企業などを
    経て2018年秋にはてなへ入社
    以後カクヨムを担当
    id: koudenpa

    View Slide

  3. 目次
    ● 背景・概要
    ● 段階的移行を追う
    ● 移行ネタ集
    ● まとめ

    View Slide

  4. 背景・概要

    View Slide

  5. 移行前構成
    ● 『はてな』アカウント
    ● IaaS(EC2)

    View Slide

  6. 移行後構成
    ● 『カクヨム』アカウント
    ● マネージドサービス
    ● コンテナ(ECS Fargate)
    ● 『はてな』少し残ってる

    View Slide

  7. なにをしたかったか
    ● 継続的な開発運用
    ● その準備として
    ● 継続的に運用できるインフラへの刷新

    View Slide

  8. やったこと・関心ごと
    ● AWSアカウント切り離し
    ● IaaSからの脱却
    ○ マネージド化
    ○ コンテナ化

    View Slide

  9. カクヨムの特性
    ● 典型的なWebアプリケーション
    ● アクセス数は増加傾向
    ○ 超高トラフィックではない
    ○ (Twitterなどではない)
    ● 一般的に良いとされる手法に倣えばよい

    View Slide

  10. モデルケース
    ● 魔法のiらんど
    ○ Hatena Engineer Seminar #14 〜魔法のiらんど編〜
    ○ https://developer.hatenastaff.com/entry/2020/09/04/093000
    ● チームの担当サービス
    ○ カクヨム
    ○ 魔法のiらんど
    ● コードベース
    ○ カクヨムと魔法のiらんどは同じ
    ■ バックエンドの処理のみ
    ○ 概ね同様の構成で動作するはず

    View Slide

  11. 移行後構成の理由
    ● モデルケースはあれども
    ● それぞれ理由はある
    ○ 魔法のiらんどでそうした理由でもある

    View Slide

  12. AWSアカウント切り離し
    ● 前
    ○ はてな全体の共有アカウント・ネットワーク
    ● 後
    ○ カクヨム専用のアカウント・ネットワーク
    ● 理由
    ○ アカウント管理のベストプラクティスに乗る
    ■ https://docs.aws.amazon.com/ja_jp/organizations/latest/use
    rguide/orgs_best-practices.html
    ○ 様々な要素の独立
    ■ AWSのレート制限
    ■ 誤操作のリスク

    View Slide

  13. マネージド化
    ● 前
    ○ IaaS(EC2)をChef管理
    ● 後
    ○ AWSの管理
    ● 理由
    ○ 管理負荷の低減
    ○ サービスを運用しやすく

    View Slide

  14. コンテナ化
    ● 前
    ○ IaaS(EC2)をChef管理
    ● 後
    ○ コンテナ環境(ECS Fargate)
    ● 理由
    ○ 一般的なコンテナ運用の利点を得る
    ○ 開発から本番まで同様の環境
    ○ 構成を変更しやすく

    View Slide

  15. 現行機能を維持
    ● 何はなくとも大目的を達成することを優先
    ○ AWSアカウント切り離し
    ○ マネージド化
    ○ コンテナ化
    ● 最適化を欲張らない
    ○ 簡単なものはやる
    ■ 今後最適化する準備まで、など

    View Slide

  16. 段階的移行
    ● カクヨムは成長中
    ○ 未来を見据えた機能追加や状況に応じた改善を止めない
    ● インフラ要素を1つずつ移行
    ○ ビッグバンで一気にではない
    ○ サービス影響のリスク・準備のコスト低減
    ○ 機能開発と並行

    View Slide

  17. 段階
    ● 永続化層
    ○ MySQL
    ○ Redis
    ○ Elasticsearch
    ● アプリケーション
    ○ Webアプリケーション
    ○ Jobワーカー
    ○ Batchサーバー
    ● ミドルウェア
    ○ Nginx, Varnish

    View Slide

  18. 移行時の対応
    ● メンテナンス有り
    ○ 10分~以上のサービスダウンやロールバック考慮
    ○ 悲観的に見た作業時間をアナウンス
    ○ リバースプロキシやCDNでメンテナンスページを応答
    ● メンテナンス無し
    ○ ~数分程度のサービスダウン
    ○ ユーザーには一定時間内にサービスにつながらない時間が
    ある旨をアナウンス
    ○ ユーザー影響はダウンしてる時間のみになる
    ● 移行以外でも同様
    ○ マネージドサービスのバージョンアップグレードなど

    View Slide

  19. 段階的移行を追う

    View Slide

  20. 移行前

    View Slide

  21. 01 ネットワーク間接続

    View Slide

  22. 01 ネットワーク間接続
    ● 移行前
    ○ AWSやオンプレミスで構成されたネットワーク
    ■ カクヨムはAWSのみ
    ● 移行後
    ○ カクヨム専用のアカウント・VPC
    ● AWS Transit Gateway(TGW)で相互接続
    ○ 段階的移行の準備
    ○ 1部のリソースだけ移動を可能に

    View Slide

  23. 02 MySQL移行

    View Slide

  24. 02 MySQL移行

    View Slide

  25. 02 MySQL移行
    ● RDS MySQL
    ● 移行前からレプリケーション
    ● 移行実施時は接続先の切り替え
    ○ メンテナンス有(安全寄せ)

    View Slide

  26. 03 Redis移行

    View Slide

  27. 03 Redis移行

    View Slide

  28. 03 Redis移行
    ● ElastiCache Redis
    ● 移行前からレプリケーション
    ● 移行実施時は接続先の切り替え
    ○ メンテナンス有(安全寄せ)

    View Slide

  29. 04 Elasticsearch移行

    View Slide

  30. 04 Elasticsearch移行

    View Slide

  31. 04 Elasticsearch移行
    ● OpenSearch Service
    ○ Amazon Elasticsearch Service の後継
    ● 移行前後にダブルライト
    ● 移行実施時は参照を切り替え
    ○ メンテナンスなし

    View Slide

  32. 05 Webアプリ移行

    View Slide

  33. 05 Webアプリ移行

    View Slide

  34. 05 Webアプリ移行
    ● ECS Fargate
    ● ローカルマシンをコンテナで動かす
    ● 本番同様の開発環境を構成して動作確認
    ● 本番構築
    ● 移行はNginxのルーティングを切り替え
    ○ メンテナンスなし

    View Slide

  35. 06 Nginx移行

    View Slide

  36. 06 Nginx移行

    View Slide

  37. 06 Nginx移行
    ● CloudFront、ECS Fagate
    ● 開発環境を構成して検証・動作確認
    ● 併せて本番環境も構成
    ● 移行はDNSを切り替え
    ○ メンテナンスなし
    ○ 切り替えミスで一部ユーザーに影響🙇

    View Slide

  38. 07 SSRサーバ追加

    View Slide

  39. 07 SSRサーバ追加
    ● ECS Fargete
    ● React導入の一環としてNext.jsのSSRサーバを追加
    ● 開発環境を構成して検証・動作確認
    ● 併せて本番環境も構成
    ● 適切な時期にリリース
    ○ メンテナンスなし

    View Slide

  40. 08 Worker/Batch移行

    View Slide

  41. 08 Worker/Batch移行

    View Slide

  42. 08 Worker/Batch移行
    ● ECS Fargate
    ● EC2上でのDocker run
    ● 開発環境を構成して検証・動作確認
    ● 併せて本番環境も構成
    ● Jobワーカーは並行稼働の後に旧環境停止
    ● Batchは旧環境停止後に新環境稼働
    ● ユーザーには見えない出来事
    ○ メンテナンスなし

    View Slide

  43. 09 ネットワーク間接続解除

    View Slide

  44. 09 ネットワーク間接続解除

    View Slide

  45. 09 ネットワーク間接続削除
    ● 削除!

    View Slide


  46. View Slide

  47. 01 ネットワーク間接続

    View Slide

  48. 02 MySQL移行

    View Slide

  49. 03 Redis移行

    View Slide

  50. 04 Elasticsearch移行

    View Slide

  51. 05 Webアプリ移行

    View Slide

  52. 06 Nginx移行

    View Slide

  53. 07 SSRサーバ追加

    View Slide

  54. 08 Worker/Batch移行

    View Slide

  55. 09 ネットワーク間接続解除

    View Slide


  56. View Slide

  57. 移行ネタ集

    View Slide

  58. おしながき
    ● やらなかったこと・残課題
    ○ 『はてな』に残っているリソース
    ○ CDN活用・キャッシュ最適化
    ○ Batchの実行環境
    ● SSRサーバへのルーティング
    ● TGWトラフィック
    ● CI/CD変遷
    ● 他

    View Slide

  59. 『はてな』に残っているリソース
    ● 『はてな』少し残ってる
    ● グローバルに一意な名前
    ● 移行パスはある
    ○ がちょっと面倒
    ● ほとんど変更しない
    ● ので差し当たって残

    View Slide

  60. CDN活用・キャッシュ最適化
    ● CDNの活用は準備まで
    ○ CloudFrontとACMでの証明書管理
    ○ 今後『層』の追加なしにカイゼンできるように
    ● Nginx, Varnish
    ○ 責務整理・最適化まで手が回らなかった

    View Slide

  61. Batchの実行環境
    ● モデルケース同様の構成
    ● EC2上のCronで docker run
    ○ 既存のスケジュールを使う
    ○ コンテナは使う
    ● アカウント切り離しとコンテナ化に注力した結果
    ● 今後クラウドネイティブ化していきたい部分

    View Slide

  62. SSRサーバへのルーティング

    View Slide

  63. SSRサーバへのルーティング
    ● SSRは『追加』
    ● 本番確認、内部の人間だけでしたい
    ● あるURLをReactでレンダリングするか判断したい
    ● そこで「X-Accel」
    ○ https://www.nginx.com/resources/wiki/start/topics/examples/x-
    accel/

    View Slide

  64. X-Accel
    ● Nginxの機能
    ● Upstreamからの応答ヘッダを見て内部リダイレクト
    ● バックエンドのアプリケーションで判断
    ○ 一般ユーザーにはHTMLをレンダリングして応答
    ○ 管理者ユーザーには X-Accel でSSR結果を応答
    ● こっそりSSRを確認できた

    View Slide

  65. X-Accel なしHTML応答
    1
    3
    2
    1. NginxからWebアプリへ
    2. WebアプリはHTML応答
    3. 素直に応答

    View Slide

  66. X-Accel してSSR結果応答
    1
    4
    3
    2
    5
    1. NginxからWebアプリへ
    2. WebアプリはX-Accel応答
    3. X-AccelならSSRサーバへ
    4. SSR!
    5. 最終的な応答

    View Slide

  67. TGWトラフィック
    ● ネットワークを超えるトラフィックがどの程度か?
    ● リソースを移行するごとに減
    ● なくなった段階でTGWを削除、お役御免

    View Slide

  68. TGWトラフィック

    View Slide

  69. TGWトラフィック
    Webアプリケーションの移行
    Nginxの移行
    Worker/Batchの移行
    PV増の様子
    ???
    永続化層(MySQL)の移行
    永続化層(MySQL)
    レプリケーション中

    View Slide

  70. CI/CD変遷
    ● インフラの移行と並行して見直し

    View Slide

  71. おわかりいただけただろうか?

    View Slide

  72. おわかりいただけただろうか?

    View Slide

  73. CI/CD変遷
    ● 前
    ○ JenkinsでのCI
    ○ 手作業でのCD
    ● 後
    ○ GitHub ActionsでのCI
    ○ AWS CodePipelineでのCD
    ● いずれも『主に』

    View Slide

  74. Jenkins
    ● 主にCIに活用
    ● チームで管理しきれていなかった
    ● マネージド化の一環
    ● 地道にジョブを置き換え
    ○ GitHub Actionsのワークフローへ

    View Slide

  75. 手作業でのCD
    ● Capistranoをローカルマシンで実行
    ● デリバリー対象の変化
    ○ ソースコード -> コンテナイメージ
    ● デリバリー先の変化
    ○ EC2 -> ECS Fargate
    ● AWSへはAWSで
    ○ CodePipelines(+CodeBuild, CodeDeploy)

    View Slide


  76. ● 気になる点があれば
    ○ 質疑応答
    ■ この後
    ○ 懇親会
    ■ セミナー後
    ○ はてなへ入社
    ■ https://hatenacorp.jp/recruit/engineer

    View Slide

  77. まとめ

    View Slide

  78. 移行前構成
    ● 『はてな』アカウント
    ● IaaS(EC2)

    View Slide

  79. 移行後構成
    ● 『カクヨム』アカウント
    ● マネージドサービス
    ● コンテナ(ECS Fargate)
    ● 『はてな』少し残ってる

    View Slide

  80. ポイント
    ● AWSアカウント切り離し
    ○ ネットワーク間接続はAWSのTGW経由
    ● ビックバンでなく1要素ずつ
    ○ マネージド化
    ○ コンテナ化
    ● 機能開発と並行
    ○ 機能リリース
    ○ React化向けのSSRサーバ追加
    ● それぞれ達成

    View Slide

  81. 得たもの
    ● マネージド化
    ○ 運用しやすく
    ● コンテナ化
    ○ 変更しやすく

    View Slide

  82. 10年を見据えて
    ● 運用しやすく
    ● 変更しやすく
    ● 今後に対応しやすくなったカクヨムにご期待ください

    View Slide

  83. つづく

    View Slide