STORES決済におけるEC2からECS Fargateへの移行〜無停止要件も添えて〜

AWS Startup Tech Meetup Online #11
https://aws-startup-community.connpass.com/event/237573/
の登壇資料です。

Transcript

1. 　　 ©hey, Inc 藤原 涼馬 ヘイ株式会社 プロダクト基盤本部 SRE STORES決済におけるEC2からECS Fargateへの移行 ~無停止要件も添えて〜
2. 自己紹介 藤原 涼馬 ヘイ株式会社 プロダクト基盤本部 SRE (他にもいろいろ) 経歴 　SIer R&D →　　　　　　→ 趣味 　自動車の運転 　模型製作 　各種寄稿・登壇 好きなAWSサービス 　ECS Fargate / AWS SSO + 他 今ここ
3. 会社概要 会社名 ヘイ株式会社 設立 2012年3月23日 代表取締役社長 佐藤裕介 資本金 1億円 所在地 〒150-0011 東京都渋谷区東3丁目16番3号　エフ・ ニッセイ恵比寿ビル4階 事業内容 インターネットビジネスの企画・開発・ 運営
4. 従業員数・職種比率 従業員数 350名 （2021/04 時点) エンジニア 31% セールス・ マーケ・事業開発 30% サポート・ サクセス 23% デザイナー 5.5% PM 2.8% コーポレート 8% エンジニア職の比率 31%
5. heyの事業 お店のデジタルを まるっとサポート。 個人や中小事業の方々に向けて、 お店のデジタル化をまるっと 実現できる価値を提供しています。
6. heyの事業 お店のデジタルを まるっとサポート。 個人や中小事業の方々に向けて、 お店のデジタル化をまるっと 実現できる価値を提供しています。 今回はこの プロダクトの話題です
7. 本日話す内容 • STORES決済では様々な改善を継続的に進めています • 改善の一環として 　Ruby on Rails実装からSpring Boot実装への切替 　Elastic Beanstalk(EC2ベース)からECS Fargateへの切替 をまとめて進めています • 切替が完全に完了したわけではありませんが、 方式の判断や判断の根拠となる考え方などを中心にお話しします (AWSのサービス除き、具体的にどんなツール使ってるかなどは末尾に紹介程度です。)
8. 　　 ©hey, Inc やろうとしたこと
9. やろうとしたこと Elastic Beanstalk ECS on Fargate Ruby on Rails Spring Boot アプリケーション層 Ruby on Rails → Spring Boot インフラ層 Elastic Beanstalk(EC2) → ECS on Fargate
10. やろうとしたこと Elastic Beanstalk ECS on Fargate Ruby on Rails Spring Boot アプリケーション層 Ruby on Rails → Spring Boot インフラ層 Elastic Beanstalk(EC2) → ECS on Fargate
11. Ruby on Rails → Spring Boot 数年かけて徐々に進めてきた案件。 メインとなる処理部分の本格的な入れ替えのフェーズ Ruby on Rails Spring Boot アプリケーション層 Ruby on Rails → Spring Boot
12. やろうとしたこと Elastic Beanstalk ECS on Fargate Ruby on Rails Spring Boot アプリケーション層 Ruby on Rails → Spring Boot インフラ層 Elastic Beanstalk(EC2) → ECS on Fargate
13. Elastic Beanstalk(EC2) → ECS on Fargate • 規模の拡大に伴い開発面で辛くなってきた(ある程度型にはめられた部分があるなど) ◦ Beanstalkの知見者があまりいないという現実もある ◦ 今後も要件が複雑化することはあってもシンプルになることはないので、 自由度を確保しつつ、管理しなければいけない部分を増やさずに維持したい • 管理しなければいけない部分を少しでも減らすことでもっと注力すべきところ に注力したい Elastic Beanstalk ECS on Fargate インフラ層 Elastic Beanstalk(EC2) → ECS on Fargate
14. ポイント このような大きな構成要素の変更は大きなリスク(や不安)が伴います。 幸い以下のような点で恵まれていた部分はあります。 • Ruby on Rails から Spring Bootへの切り替えは既定路線 (あとはHowの問題だった) • 合わせてECS Fargateへの載せ替えも実施したかった
15. ポイント このような大きな構成要素の変更は大きなリスク(や不安)が伴います。 幸い以下のような点で恵まれていた部分はあります。 • Ruby on Rails から Spring Bootへの切り替えは既定路線 (あとはHowの問題だった) • 合わせてECS Fargateへの載せ替えも実施したかった 次のスライド以降では、 どうリスクを小さくしていくかという基本的な考え方と その中でどういう選択をしたのかを解説します。
16. 　　 ©hey, Inc 移行に伴う 基本的な考え方
17. STORES決済の立ち位置 • 実店舗でのキャッシュレス決済を担う • ミッションクリティカルです ◦ さまざまな業態の店舗の決済を担っている関係上、 原則として24/365での動作が期待されます
18. STORES決済の立ち位置 • 実店舗でのキャッシュレス決済を担う • ミッションクリティカルです ◦ さまざまな業態の店舗の決済を担っている関係上、 原則として24/365での動作が期待されます
19. やろうとしたこと Elastic Beanstalk ECS on Fargate Ruby on Rails Spring Boot アプリケーション層 Ruby on Rails → Spring Boot インフラ層 Elastic Beanstalk(EC2) → ECS on Fargate いかにして安全に切り替えるかが重要になります
20. 安全に切り替えるとは？ 1. 切替先が正しく動作するように算段する
21. 安全に切り替えるとは？ 1. 切替先が正しく動作するように算段する ◦ 自動テストを充実させる ◦ QAによる各種探索テストを実施する アプリケーション実装の話
22. 安全に切り替えるとは？ 1. 切替先が正しく動作するように算段する ◦ 自動テストを充実させる ◦ QAによる各種探索テストを実施する 2. 問題が起きてもすぐに戻せるようにする アプリケーション実装の話
23. 安全に切り替えるとは？ 1. 切替先が正しく動作するように算段する ◦ 自動テストを充実させる ◦ QAによる各種探索テストを実施する 2. 問題が起きてもすぐに戻せるようにする ◦ Point of No Return(PNR)を時間軸的に後ろに寄せる ◦ データの修復やリカバリも含む(が、今回は対象外) アプリケーション実装の話
24. 安全に切り替えるとは？ 1. 切替先が正しく動作するように算段する ◦ 自動テストを充実させる ◦ QAによる各種探索テストを実施する 2. 問題が起きてもすぐに戻せるようにする ◦ Point of No Return(PNR)を時間軸的に後ろに寄せる ◦ データの修復やリカバリも含む(が、今回は対象外) アプリケーション実装の話 PNR スタート ゴール まだ戻れる もう戻れない PNR スタート ゴール まだ戻れる もう戻れない まだ戻れる まだ戻れる PNRが手前 = リスクが大きい状態 PNRが後ろ = リスクが小さい状態
25. 安全に切り替えるとは？ 1. 切替先が正しく動作するように算段する ◦ 自動テストを充実させる ◦ QAによる各種探索テストを実施する 2. 問題が起きてもすぐに戻せるようにする ◦ Point of No Return(PNR)を時間軸的に後ろに寄せる ◦ データの修復やリカバリも含む(が、今回は対象外) アプリケーション実装の話 PNR スタート ゴール まだ戻れる もう戻れない PNR スタート ゴール まだ戻れる もう戻れない まだ戻れる まだ戻れる PNRが手前 = リスクが大きい状態 PNRが後ろ = リスクが小さい状態 こちらをメインでお話します
26. 　　 ©hey, Inc RoR実装から Spring Boot実装への切替
27. 安全に切り替える方法 ローリングデプロイ 多数ある冗長化されたコンポーネントを徐々に入れ替える ブルーグリーンデプロイ 環境を2面用意し、一気に切り替える カナリアデプロイ パフォーマンスやエラーの発生をモニタリングしながら徐々に入れ替える https://speakerdeck.com/rtechkouhou/devopsdao-ru-zhi-nan-ji-ben-bian-26c1a9dc-d1a8-4b3a-b7f4-39cb241c5831 より抜粋
28. CloudFront distribution Beanstalk Environment Blue 改めて移行前の状態を見てみる 移行前の構成 Beanstalk Environment Green
29. CloudFront distribution Beanstalk Environment Blue 改めて移行前の状態を見てみる 移行前の構成 Beanstalk Environment Green シンプルかつ素朴な構成
30. CloudFront distribution Beanstalk Environment Blue 改めて移行前の状態を見てみる デプロイの流れを見てみます Beanstalk Environment Green 新しいバージョンをリリース
31. CloudFront distribution Beanstalk Environment Blue 改めて移行前の状態を見てみる デプロイの流れを見てみます Beanstalk Environment Green QA 別経路からQA実施
32. CloudFront distribution Beanstalk Environment Blue 改めて移行前の状態を見てみる デプロイの流れを見てみます Beanstalk Environment Green URLスワップで リクエストの方向を切り替え
33. CloudFront distribution Beanstalk Environment Blue 改めて移行前の状態を見てみる デプロイの流れを見てみます Beanstalk Environment Green URLスワップで リクエストの方向を切り替え 典型的なブルーグリーンデプロイ
34. 安全に切り替える方法 ローリングデプロイ 多数ある冗長化されたコンポーネントを徐々に入れ替える ブルーグリーンデプロイ 環境を2面用意し、一気に切り替える カナリアデプロイ パフォーマンスやエラーの発生をモニタリングしながら徐々に入れ替える https://speakerdeck.com/rtechkouhou/devopsdao-ru-zhi-nan-ji-ben-bian-26c1a9dc-d1a8-4b3a-b7f4-39cb241c5831 より抜粋
35. この時点(切り替え前)のSpring Boot実装の状態 • 機能的には動作するはず • 今回デプロイする範囲がプロダクションの負荷に耐えられるかは未知数
36. この時点(切り替え前)のSpring Boot実装の状態 • 機能的には動作するはず • 今回デプロイする範囲がプロダクションの負荷に耐えられるかは未知数 本番と同等の負荷を流すことはその時点では、 構成上難しい(社外との連携もあるため)
37. 安全に切り替える方法 ローリングデプロイ 多数ある冗長化されたコンポーネントを徐々に入れ替える ブルーグリーンデプロイ 環境を2面用意し、一気に切り替える カナリアデプロイ パフォーマンスやエラーの発生をモニタリングしながら徐々に入れ替える https://speakerdeck.com/rtechkouhou/devopsdao-ru-zhi-nan-ji-ben-bian-26c1a9dc-d1a8-4b3a-b7f4-39cb241c5831 より抜粋
38. 安全に切り替える方法 ローリングデプロイ 多数ある冗長化されたコンポーネントを徐々に入れ替える ブルーグリーンデプロイ 環境を2面用意し、一気に切り替える カナリアデプロイ パフォーマンスやエラーの発生をモニタリングしながら徐々に入れ替える https://speakerdeck.com/rtechkouhou/devopsdao-ru-zhi-nan-ji-ben-bian-26c1a9dc-d1a8-4b3a-b7f4-39cb241c5831 より抜粋 ブルーグリーンデプロイとカナリアデプロイの両方 を組み合わせて利用
39. ECS on Fargate CloudFront distribution Beanstalk Environment Blue RoR, Spring Boot実装の並行運用の状態 切替中の構成 Beanstalk Environment Green ECS on Fargate
40. ECS on Fargate CloudFront distribution Beanstalk Environment Blue RoR, Spring Boot実装の並行運用の状態 RoR実装の修正、デプロイ、リリースを行う場合 Beanstalk Environment Green ECS on Fargate URLスワップをつかった B/Gデプロイ（先ほど説明）
41. ECS on Fargate CloudFront distribution Beanstalk Environment Blue RoR, Spring Boot実装の並行運用の状態 RoRの場合と似通ってますがもう少し具体的に解説 Beanstalk Environment Green ECS on Fargate CodeDeploy CodeDeploy をつかった B/Gデプロイ
42. ECS on Fargate CloudFront distribution Beanstalk Environment Blue RoR, Spring Boot実装の並行運用の状態 Beanstalk Environment Green ECS on Fargate CodeDeploy リクエストの流れていない 面にB/Gデプロイ 新ver
43. ECS on Fargate CloudFront distribution Beanstalk Environment Blue RoR, Spring Boot実装の並行運用の状態 Beanstalk Environment Green ECS on Fargate CodeDeploy 新ver QA 別経路からQA実施
44. ECS on Fargate CloudFront distribution Beanstalk Environment Blue RoR, Spring Boot実装の並行運用の状態 Beanstalk Environment Green ECS on Fargate CodeDeploy 新ver URLスワップで リクエストの方向を切り替え
45. ECS on Fargate CloudFront distribution Beanstalk Environment Blue RoR, Spring Boot実装の並行運用の状態 Beanstalk Environment Green ECS on Fargate 新ver 不具合の再現環境など として利用する
46. ECS on Fargate CloudFront distribution Beanstalk Environment Blue RoR, Spring Boot実装の並行運用の状態 Beanstalk Environment Green ECS on Fargate この仕組みでRoR実装とSpring Boot実装を独立かつ、 切り戻しも含めたデプロイとリリースが可能に
47. ECS on Fargate CloudFront distribution Beanstalk Environment Blue RoR, Spring Boot実装の並行運用の状態 Beanstalk Environment Green ECS on Fargate
48. ECS on Fargate CloudFront distribution Beanstalk Environment Blue RoR, Spring Boot実装の並行運用の状態 Beanstalk Environment Green ECS on Fargate 安全側に倒して、流量を厳密に制御したい
49. Spring Boot実装への 流量制御(カナリアリリース) もう少し詳細な図で説明 Listener Listener Rule Listener Rule Listener Rule RoR実装 (Elastic Beanstalk) Spring Boot実装 (ECS Fargate)
50. Spring Boot実装への 流量制御(カナリアリリース) もう少し詳細な図で説明 Listener Listener Rule Listener Rule Listener Rule RoR実装 (Elastic Beanstalk) Spring Boot実装 (ECS Fargate) ヘッダルーティングと、 加重ルーティングを使って Spring Boot実装への流量を制御 上記はほとんど切替後のものなので参考までに
51. Spring Boot実装への 流量制御(カナリアリリース) リソースの状況やエラー発生率などをモニタリングしながら Spring Boot実装への流量解放のスケジュールを設定
52. Spring Boot実装への 流量制御(カナリアリリース) リソースの状況やエラー発生率などをモニタリングしながら Spring Boot実装への流量解放のスケジュールを設定 数値に基づいてGo・Stop・Return判断をする
53. ここまでのまとめ • Point of No Returnを可能 な限り後ろに倒しましょう • 様々なデプロイ手法を駆使して リスクを最小にしましょう • 数値(= 客観的事実)に基づいて Go・Stop・Returnの判断をしましょう
54. 　　 ©hey, Inc もう少し具体的な 技術の話
55. もう少し具体的な技術や流れの話を解説 • コンテナイメージのビルドをどうしているか？ • デプロイの流れをどうしているか？
56. もう少し具体的な技術や流れの話を解説 • コンテナイメージのビルドをどうしているか？ • デプロイの流れをどうしているか？
57. コンテナイメージのビルドにおける大前提 • Dockerfileは書きたくない ◦ なんらアプリケーションコードとしては特別な事はしていないので Dockerfileの管理にパワーを費やしたくない
58. コンテナイメージのビルドにおけるツール選定 • Dockerfileは書きたくない ◦ なんらアプリケーションコードとしては特別な事はしていないので Dockerfileの管理にパワーを費やしたくない Spring Boot(Java)なので、 GoogleContainerTools/jib を利用 https://github.com/GoogleContainerTools/jib
59. コンテナイメージのビルドにおけるツール選定 • Dockerfileは書きたくない ◦ なんらアプリケーションコードとしては特別な事はしていないので Dockerfileの管理にパワーを費やしたくない Spring Boot(Java)なので、 GoogleContainerTools/jib を利用 https://github.com/GoogleContainerTools/jib Cloud Native Buildpacks https://buildpacks.io/ Openshift s2i https://github.com/openshift/source-to-image 他のDockerfileレスイメージビルドにおける選択肢 Java以外でDockerfileレスなイメージビルドするなら上記2つから選ぶ
60. もう少し具体的な技術や流れの話を解説 • コンテナイメージのビルドをどうしているか？ • デプロイの流れをどうしているか？
61. デプロイの流れ • GitHub Actionsを利用してデプロイ（既存と同様のサービスを利用） ◦ リポジトリのタグを指定してデプロイする形 ◦ コンテナイメージは、 別のGitHub Actionsワークフローでビルド & テスト済のイメージを利用します 主に使っているAWS関連のGitHubアクション • aws-actions/configure-aws-credentials • aws-actions/amazon-ecs-render-task-definition • aws-actions/amazon-ecs-deploy-task-definition
62. 技術的な部分についてのまとめ • Dockerfileを管理しなくていいようにくらいのこだわりしかないです • 攻めの部分についてはデプロイ全体の流れで攻め切ったため、 ツールの部分についてはチャレンジはあまりしていません。 強いて言うのであれば、 チャレンジする領域と保守的にする領域を明確に分けるようにする のはあとから振り返って効果を判断する上で重要そうです。
63. エンジニア大!大!大!募集中です https://hello.hey.jp/engineer
64. MORE INFO heyのオープンな社内報 hey note https://days.hey.jp/ Tech イベント hey connpass https://hey.connpass.com/ プロダクト開発の裏側を発信中 hey Product Blog https://tech.hey.jp/ heyのメディア hey MAGAZINE https://mag.hey.jp プロダクトのこと、技術のこと色々お話しましょう カジュアル面談 (Meety) https://meety.net/ heyのひとびとを伝える動画 hey People https://vimeo.com/heyinc
65. ご清聴ありがとうございました!