[Amazon EKS on AWS Fargate] スタートアップの "次の3年" を支えるためのインフラ技術 / AWS DEV DAY EKS ON FARGATE

AWS DEV DAY 2022 登壇資料です。

プロダクトのローンチから2年が経った私たちのチームには、今後より大きくスケールし、より早く改善を続けるためのアーキテクチャが必要になっていました。そこで私たちは、 ’次の3年’ の事業の成長を支えるために、Amazon EKS を軸としながらサーバーレス技術を積極的に取り入れていく、という方針を採ることとしました。

本セッションでは、EKS on Fargate を中心とした モバイルを含めたアプリケーションのバックエンドシステムを構築・運用するための勘所についてのナレッジを共有します。

https://github.com/aws-events/aws-dev-day-online-japan-2022-cfp/issues/45

Transcript

1. Nov 9, 2022 C - 1 [Amazon EKS on AWS Fargate] スタートアップの "次の3年" を支えるためのインフラ技術 池内 孝啓 - Takahiro Ikeuchi Awarefy CTO
2. Agenda 自己紹介 スタートアップにとっての技術選定とは これまでの3年と、mBaaS の運用で生まれた課題 "次の3年" を支えるためのインフラ技術 まとめ 1. 2. 3. 4. 5. 💡 本資料はセッション後に公開いたします
3. 池内 孝啓（いけうち たかひろ） 株式会社Hakali 取締役CTO 自己紹介 Web フロントエンド、モバイル、バックエンドからインフラまで こなすマルチスタック・ソフトウェアエンジニア。 2015年に株式会社ALBERTにて東証マザーズへのIPOを経験。その後起業〜廃業を経て 2019年より現職。デジタル認知行動療法アプリ Awarefy を 2020年にローンチ。 アマゾンウェブサービス（AWS）利用歴10年〜。
4. 執筆技術書 著者ページ : https://www.amazon.co.jp/~/e/B00W961N5O
5. Follow me! https://github.com/iktakahiro https://iktakahiro.dev/ @iktakahiro https://www.awarefy.app 5
6. 私たちが解決したいこと 国内外の精神疾患患者数は年々増加傾向に あり、近年特にうつ病をはじめとする 気分障害の患者数が急速に増加。 こころの病気は生涯を通じて5人に1人が かかるとも言われています。 資料:厚生労働省「患者調査」 https://www.mhlw.go.jp/toukei/list/10-20.html
7. メンタルヘルスに課題を抱えた人に対する 適切なケアが十分に届いていない・わかりやすく 提供されていない。 時間的制約・距離的制約・精神疾患に対するスティグマ 課題 いつでも気軽に取り組めるアプリを通じて、 メンタルケアを自分で・簡単に・わかりやすく 行えるような仕組みを提供する。 解決策 わたしたちが実現したいこと
8. デジタル認知行動療法アプリ「Awarefy」
9. カラダとココロの状態に気づく ことができると、安心します。 毎日のセルフモニタリング コンディション 寝る前や朝起きたときに、 自分を整える習慣ができました。 自分の感情を客観的に理解できる いい機会になっています。 感情メモ 自分の感情がひと目で分かる 解決策：認知行動療法をアプリで © Hakali Inc. 豊富なマインドフルネス瞑想 音声ガイド
10. シード 〜 アーリーステージのスタートアップにとって 技術選定とは 10
11. 5 〜 10年くらい ？ スタートアップのステージ シード アーリー ミドル レイター
12. スタートアップのステージ シード アーリー ミドル レイター イマココ
13. エンジニア人数 1-3人 プロダクトの不確実性 極めて高い 最優先事項 Problem Solution Fit シード期の状況 ※ 企業や事業ドメイン、マーケットによってことなります
14. シード期の技術選定 Pivot をくり返す可能性が高いため、システムの作り込みを できるだけ遅延させる No-Code, Low-Code で進めるならそれがベスト BaaS, mBaaS の活用を有力選択肢に入れておく
15. エンジニア人数 2-5人 プロダクトの不確実性 高い 最優先事項 Product Market Fit アーリー期の状況 ※ 企業や事業ドメイン、マーケットによってことなります 15
16. アーリー期の技術選定 プロダクトや事業の不確実性は依然として高い PMFに向けた仮説検証のアジリティを確保しつつ 将来のスケーラビリティ確保に向き合う シード期のシステムのリアーキテクチャを行うかも含めて 意志決定を迫られる難しい時期
17. 技術選定 = 投資であり、事業戦略 技術選定は将来に向けて 行われるべき 採用 生産性 コスト 楽しさ 将来性 安定性 キャリア ブランド どこに投資するかという 意志決定もある トレンド 好み
18. これまでの3年
19. おもな技術スタック - 2019 〜 2021 Flutter mBaaS モバイルアプリ NoSQL on mBaaS
20. Flutter 1ソースで iOS / Android の両プラットフォームに対応できる デスクトップアプリやWebアプリにも拡張可能 エコシステムが充実しており開発体験に優れる 選定の理由 エンジニアが少数（というか1名）だったため これからムーブメントが来そうという予感がしていたため 20
21. NoSQL on mBaaS インフラの管理、バックエンドアプリの実装と運用を （ほぼ）用意しなくてよいのが最大の利点 エンジニアが（以下同文 Flutter との相性がよい（と思った） 選定の理由
22. NoSQL のデメリットの顕在化 サーバーサイド・アプリがないことのデメリットの顕在化 悩んだ点 Flutter の選定 プロダクトのローンチの成功、運用面での大きな障害が 起きなかった → mBaaS の力によるところが大きい 良かった点 ローンチして2年、技術選定のふり返り
23. NoSQL on mBaaS の運用で生まれた課題 データの集計がし難い、できない データの正規化ができない バックアップ、リストアのオペレーションが不安 アクセス設定、セキュリティ周りの権限設定に柔軟性がない
24. いずれも、導入時点で想定しうる内容ではある 事業フェーズとのミスマッチが思っていたよりは早く 来てしまった。あくまでマッチングの問題 NoSQL on mBaaS の運用で生まれた課題
25. 将来のための リアークテクチャ 直近の スピード感 変えるべきか、留まるべきか、それが問題だ。 25
26. 中長期でみて事業のスピード感が損なわれれば、意志決定は 妥当ではなかったと見なされる うまくいけば、成功事例と見なされる どのような技術選定をしても、 事業が成長しなければ（事業的な）価値はない
27. NoSQL や mBaaS のデメリットの解消 解決したかったこと ではなく
28. ビジネスモデルとシステムアーキテクチャを統合し、 Moat（競合優位性）を生み出すこと 解決したかったこと
29. 2020年5月ローンチ、mBaaS による完全サーバーレス 2022年7月にAWSに移行を実施 2022年2月頃より移行準備を開始
30. "次の3年" を支えるためのインフラ技術 30
31. mBaaS のデメリットを解消しつつ たしかにあったメリットをできるだけ失わないこと 少人数で運用できるよう自動化・コード化を前提とする 技術的挑戦をする・攻めの姿勢！ インフラ移行・リアーキテクチャのテーマ
32. 目的はあくまでも Moat（競合優位性）を生み出すこと
33. おもな技術スタック - 2022 〜 Flutter Go Protocol Buffers / gRPC PostgreSQL GitHub Actions Argo CD
34. 構成図
35. AWSのおもな採用サービス・ツール Amazon Elastic Kubernetes Service (EKS) AWS Fargate Amazon Aurora Serverless v2 AWS Cloud Development Kit (CDK) 35
36. Flutter 続投 選定の理由
37. Go ミニマルなバックエンドシステムとしての豊富な採用実績 コンテナ運用との相性の良さ 選定の理由
38. 選定の理由 Protocol Buffers / gRPC インターフェースドリブンなシステム設計 クライアント（Dart）、サーバー（Go）のコードの自動生成 alt-RESTFul API としてのナレッジを獲得するため gRPCのWebサーバーをAWSで運用するTipsはのちほど
39. Amazon Elastic Kubernetes Service (EKS) リリースまでの最短ルートを目指すなら Amazon Elastic Container Service (Amazon ECS) も 選択肢に 技術投資をするなら Kubernetes と判断 AWS CDK との組み合わせで構築コストを最小化（後述） 選定の理由
40. AWS Fargate - (Amazon EKS on AWS Fargate) Amazon EKS において Amazon Elastic Compute Cloud (Amazon EC2) を運用しないための唯一の選択肢 サーバーレスの継続 選定の理由 40
41. Amazon Aurora Serverless v2 No-NoSQL（つまりRDB）な DBの選択肢としては一択 フルマネージドの利点と、サーバーレスの利点を合わせ持つ 2022年4月22日に一般公開されたばかり 技術的挑戦を忘れない 選定の理由
42. AWS Cloud Development Kit (CDK) AWS CloudFormation を管理していく戦略のひとつとして 途中から Infrastructure as Code の大変さを被らないため に最初から投入していく TypeScript バージョンを採用 選定の理由
43. Amazon EKS の採用について Q1. マイクロサービス化しているの？ A1. していません Q2. アクセス数が膨大だったりするの？ A2. まだまだ伸びしろあります （累計約 20万ユーザー）
44. Amazon Elastic Container Service (Amazon ECS) もじゅうぶん巨人ですけどね 少人数のチームが（マイクロサービス化もしていないのに） Amazon EKS を採用する理由 巨人（ = k8s エコシステム）の肩に乗る 一度構築できてしまえば運用は大変ではない 構築は Amazon EKS Blueprints for CDK がオススメ（次頁）
45. AWS の構成管理を「コード」で行える TypeScript や Python、Go、Java などをサポート https://github.com/aws/aws-cdk https://docs.aws.amazon.com/cdk/v2/guide/multiple_languages.html AWS Cloud Development Kit (CDK) 45
46. Amazon EKS のための Amazon CDK TIPS
47. Q. Cloud Formation で Infrastructure as Code は実現できるのではでしょうか？
48. たしかにそうですが、 あれは YAML です。
49. AWS の構成管理を「コード」で行える https://github.com/aws/aws-cdk AWS Cloud Development Kit (CDK)
50. AWS CDK を使うことで YAML職人から脱却できる 50
51. AWS Cloud Development Kit (CDK)
52. とにかく依存関係が多い Amazon Virtual Private Cloud (Amazon VPC) Subnet groups, AWS Security Groups etc... 構築に20分程度はかかり試行錯誤が大変 AWS CDK + Amazon EKS つまづきポイント
53. AWS Cloud Development Kit (CDK) https://aws-quickstart.github.io/cdk-eks-blueprints/ Well-Architected な Amazon EKS クラスターを構築するための 秘伝（？）のレシピが搭載されたライブラリ群
54. たったこれだけのコードで（※） Amazon VPC の設定にはじまり、ネットワークレイヤの設定を 自動で行ったうえで Amazon EKS の構築を始めてくれる（！） ※ 実際はもうちょっと書きますが、全体で50行くらい
55. External Secrets Operator (ESO) や Argo CD など、 Kubernetes の運用に必要なサービスをあわせて導入できる 豊富な Addon 55
56. Infrastructure as Code / GitOps Open ID Connect で GitHub 上の 特定リポジトリからのCDK実行を許可 https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security- hardening-with-openid-connect
57. Amazon EKS 構築 TIPS
58. AWS の構成管理を「コード」で行える https://github.com/aws/aws-cdk AWS Cloud Development Kit (CDK) Amazon EKS Blueprints その後 Amazon EKS のクラスタ構築後は、 Kubernetes Manifest を書こう AWS の関心事が関係する Manifest は 仕様やバージョンに特に注意して進める
59. Elastic Load Balancing (ELB) / Application Load Balancer (ALB) は Ingress として定義する
60. Protocol Buffers / gRPC（再掲） インターフェースドリブンなシステム設計 クライアント（Dart）、サーバー（Go）のコードの自動生成 alt-RESTFul API としてのナレッジを獲得するため 選定の理由 60
61. AWS の構成管理を「コード」で行える https://github.com/aws/aws-cdk AWS Cloud Development Kit (CDK) gRPC を対象とする Web アプリを運用する場合、下記3つに注意 ALB 関連のオプションを gRPC 向けの内容にする ALB からのヘルスチェックにアプリ側で応答する Pod（コンテナ）内のヘルスチェックに対応する
62. ALB からのヘルスチェックにアプリ側で応答する ALB からのヘルスチェックにアプリ側で応答する 定義したパス（サービス）で所定のレスポンスを返す https://github.com/grpc-ecosystem/grpc-health-probe grpc-health-probe の利用が便利
63. AWS の構成管理を「コード」で行える https://github.com/aws/aws-cdk AWS Cloud Development Kit (CDK) AWS Fargate 用の Deployment 1 Pod = 1 Fargate Node vCPUとメモリの値を指定
64. AWS の構成管理を「コード」で行える https://github.com/aws/aws-cdk AWS Cloud Development Kit (CDK) Amazon EKS on AWS Fargate 注意点 Daemon Set 未対応 シークレット管理の選択肢が限られる Sidecar は対応してます AWS Graviton プロセッサ未対応 対応に期待
65. AWS の構成管理を「コード」で行える https://github.com/aws/aws-cdk AWS Cloud Development Kit (CDK) Amazon EKS とシークレット管理 スマートな解決策は現状提示されていない https://github.com/aws/secrets-store-csi-driver-provider-aws https://github.com/external-secrets/external-secrets Secrets Store CSI Driver が有力だが、Daemon Set の使えな い AWS Farget では利用できない External Secrets Operator を採用 65
66. Amazon EKS 運用 TIPS
67. AWS の構成管理を「コード」で行える https://github.com/aws/aws-cdk AWS Cloud Development Kit (CDK) RDB マイグレーションどこでやろう問題 シークレット管理と並ぶ運用課題2大あるあるの1つ Pod の起動前に DBマイグレーション こっちも起動したから DBマイグレーション Replica set : 2
68. AWS の構成管理を「コード」で行える https://github.com/aws/aws-cdk AWS Cloud Development Kit (CDK)
69. AWS の構成管理を「コード」で行える https://github.com/aws/aws-cdk AWS Cloud Development Kit (CDK) Amazon EKS とDB マイグレーション Argo CD を使おう Manifest 運用を GitOps で遂行するための便利ツール https://argoproj.github.io/
70. Infrastructure as Code / Git Ops GitHub 上の差分を検知して Manifest を適用（SYNC) SYNC の前後に HOOK を仕込むことが できる この仕組みを利用して、 DB マイグレーションを実行する 70
71. 移行プロジェクトの結果
72. AWS の構成管理を「コード」で行える https://github.com/aws/aws-cdk AWS Cloud Development Kit (CDK) 技術チーム約3名で、インフラ設計、バックエンド実装、 データマイグレーションを遂行 構想8ヶ月、実行半年 もちろん課題や積み残しはあるものの、AWS 化計画を達成 移行プロジェクトの結果
73. まとめ
74. なぜ "3年" なのか シード アーリー ミドル レイター 恐らく3年後には次の次のステージを （チームが）見据えているはず そのときまで事業をブーストできる インフラ基盤をいまつくる
76. See you again at the next stage!! @iktakahiro