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

by Takahiro Ikeuchi

Slide 1

Slide 1 text

Nov 9, 2022 C - 1 [Amazon EKS on AWS Fargate] スタートアップの "次の3年" を支えるためのインフラ技術池内孝啓 - Takahiro Ikeuchi Awarefy CTO

Slide 2

Slide 2 text

Agenda 自己紹介スタートアップにとっての技術選定とはこれまでの3年と、mBaaS の運用で生まれた課題 "次の3年" を支えるためのインフラ技術まとめ 1. 2. 3. 4. 5. 💡 本資料はセッション後に公開いたします

Slide 3

Slide 3 text

池内孝啓（いけうちたかひろ）株式会社Hakali 取締役CTO 自己紹介 Web フロントエンド、モバイル、バックエンドからインフラまでこなすマルチスタック・ソフトウェアエンジニア。 2015年に株式会社ALBERTにて東証マザーズへのIPOを経験。その後起業〜廃業を経て 2019年より現職。デジタル認知行動療法アプリ Awarefy を 2020年にローンチ。アマゾンウェブサービス（AWS）利用歴10年〜。

Slide 4

Slide 4 text

執筆技術書著者ページ : https://www.amazon.co.jp/~/e/B00W961N5O

Slide 5

Slide 5 text

Follow me! https://github.com/iktakahiro https://iktakahiro.dev/ @iktakahiro https://www.awarefy.app 5

Slide 6

Slide 6 text

私たちが解決したいこと国内外の精神疾患患者数は年々増加傾向にあり、近年特にうつ病をはじめとする気分障害の患者数が急速に増加。こころの病気は生涯を通じて5人に1人がかかるとも言われています。資料:厚生労働省「患者調査」 https://www.mhlw.go.jp/toukei/list/10-20.html

Slide 7

Slide 7 text

メンタルヘルスに課題を抱えた人に対する適切なケアが十分に届いていない・わかりやすく提供されていない。時間的制約・距離的制約・精神疾患に対するスティグマ課題いつでも気軽に取り組めるアプリを通じて、メンタルケアを自分で・簡単に・わかりやすく行えるような仕組みを提供する。解決策わたしたちが実現したいこと

Slide 8

Slide 8 text

デジタル認知行動療法アプリ「Awarefy」

Slide 9

Slide 9 text

カラダとココロの状態に気づくことができると、安心します。毎日のセルフモニタリングコンディション寝る前や朝起きたときに、自分を整える習慣ができました。自分の感情を客観的に理解できるいい機会になっています。感情メモ自分の感情がひと目で分かる解決策：認知行動療法をアプリで © Hakali Inc. 豊富なマインドフルネス瞑想音声ガイド

Slide 10

Slide 10 text

シード〜アーリーステージのスタートアップにとって技術選定とは 10

Slide 11

Slide 11 text

5 〜 10年くらい？スタートアップのステージシードアーリーミドルレイター

Slide 12

Slide 12 text

スタートアップのステージシードアーリーミドルレイターイマココ

Slide 13

Slide 13 text

エンジニア人数 1-3人プロダクトの不確実性極めて高い最優先事項 Problem Solution Fit シード期の状況 ※ 企業や事業ドメイン、マーケットによってことなります

Slide 14

Slide 14 text

シード期の技術選定 Pivot をくり返す可能性が高いため、システムの作り込みをできるだけ遅延させる No-Code, Low-Code で進めるならそれがベスト BaaS, mBaaS の活用を有力選択肢に入れておく

Slide 15

Slide 15 text

エンジニア人数 2-5人プロダクトの不確実性高い最優先事項 Product Market Fit アーリー期の状況 ※ 企業や事業ドメイン、マーケットによってことなります 15

Slide 16

Slide 16 text

アーリー期の技術選定プロダクトや事業の不確実性は依然として高い PMFに向けた仮説検証のアジリティを確保しつつ将来のスケーラビリティ確保に向き合うシード期のシステムのリアーキテクチャを行うかも含めて意志決定を迫られる難しい時期

Slide 17

Slide 17 text

技術選定 = 投資であり、事業戦略技術選定は将来に向けて行われるべき採用生産性コスト楽しさ将来性安定性キャリアブランドどこに投資するかという意志決定もあるトレンド好み

Slide 18

Slide 18 text

これまでの3年

Slide 19

Slide 19 text

おもな技術スタック - 2019 〜 2021 Flutter mBaaS モバイルアプリ NoSQL on mBaaS

Slide 20

Slide 20 text

Flutter 1ソースで iOS / Android の両プラットフォームに対応できるデスクトップアプリやWebアプリにも拡張可能エコシステムが充実しており開発体験に優れる選定の理由エンジニアが少数（というか1名）だったためこれからムーブメントが来そうという予感がしていたため 20

Slide 21

Slide 21 text

NoSQL on mBaaS インフラの管理、バックエンドアプリの実装と運用を（ほぼ）用意しなくてよいのが最大の利点エンジニアが（以下同文 Flutter との相性がよい（と思った）選定の理由

Slide 22

Slide 22 text

NoSQL のデメリットの顕在化サーバーサイド・アプリがないことのデメリットの顕在化悩んだ点 Flutter の選定プロダクトのローンチの成功、運用面での大きな障害が起きなかった → mBaaS の力によるところが大きい良かった点ローンチして2年、技術選定のふり返り

Slide 23

Slide 23 text

NoSQL on mBaaS の運用で生まれた課題データの集計がし難い、できないデータの正規化ができないバックアップ、リストアのオペレーションが不安アクセス設定、セキュリティ周りの権限設定に柔軟性がない

Slide 24

Slide 24 text

いずれも、導入時点で想定しうる内容ではある事業フェーズとのミスマッチが思っていたよりは早く来てしまった。あくまでマッチングの問題 NoSQL on mBaaS の運用で生まれた課題

Slide 25

Slide 25 text

将来のためのリアークテクチャ直近のスピード感変えるべきか、留まるべきか、それが問題だ。 25

Slide 26

Slide 26 text

中長期でみて事業のスピード感が損なわれれば、意志決定は妥当ではなかったと見なされるうまくいけば、成功事例と見なされるどのような技術選定をしても、事業が成長しなければ（事業的な）価値はない

Slide 27

Slide 27 text

NoSQL や mBaaS のデメリットの解消解決したかったことではなく

Slide 28

Slide 28 text

ビジネスモデルとシステムアーキテクチャを統合し、 Moat（競合優位性）を生み出すこと解決したかったこと

Slide 29

Slide 29 text

2020年5月ローンチ、mBaaS による完全サーバーレス 2022年7月にAWSに移行を実施 2022年2月頃より移行準備を開始

Slide 30

Slide 30 text

"次の3年" を支えるためのインフラ技術 30

Slide 31

Slide 31 text

mBaaS のデメリットを解消しつつたしかにあったメリットをできるだけ失わないこと少人数で運用できるよう自動化・コード化を前提とする技術的挑戦をする・攻めの姿勢！インフラ移行・リアーキテクチャのテーマ

Slide 32

Slide 32 text

目的はあくまでも Moat（競合優位性）を生み出すこと

Slide 33

Slide 33 text

おもな技術スタック - 2022 〜 Flutter Go Protocol Buffers / gRPC PostgreSQL GitHub Actions Argo CD

Slide 34

Slide 34 text

構成図

Slide 35

Slide 35 text

AWSのおもな採用サービス・ツール Amazon Elastic Kubernetes Service (EKS) AWS Fargate Amazon Aurora Serverless v2 AWS Cloud Development Kit (CDK) 35

Slide 36

Slide 36 text

Flutter 続投選定の理由

Slide 37

Slide 37 text

Go ミニマルなバックエンドシステムとしての豊富な採用実績コンテナ運用との相性の良さ選定の理由

Slide 38

Slide 38 text

選定の理由 Protocol Buffers / gRPC インターフェースドリブンなシステム設計クライアント（Dart）、サーバー（Go）のコードの自動生成 alt-RESTFul API としてのナレッジを獲得するため gRPCのWebサーバーをAWSで運用するTipsはのちほど

Slide 39

Slide 39 text

Amazon Elastic Kubernetes Service (EKS) リリースまでの最短ルートを目指すなら Amazon Elastic Container Service (Amazon ECS) も選択肢に技術投資をするなら Kubernetes と判断 AWS CDK との組み合わせで構築コストを最小化（後述）選定の理由

Slide 40

Slide 40 text

AWS Fargate - (Amazon EKS on AWS Fargate) Amazon EKS において Amazon Elastic Compute Cloud (Amazon EC2) を運用しないための唯一の選択肢サーバーレスの継続選定の理由 40

Slide 41

Slide 41 text

Amazon Aurora Serverless v2 No-NoSQL（つまりRDB）な DBの選択肢としては一択フルマネージドの利点と、サーバーレスの利点を合わせ持つ 2022年4月22日に一般公開されたばかり技術的挑戦を忘れない選定の理由

Slide 42

Slide 42 text

AWS Cloud Development Kit (CDK) AWS CloudFormation を管理していく戦略のひとつとして途中から Infrastructure as Code の大変さを被らないために最初から投入していく TypeScript バージョンを採用選定の理由

Slide 43

Slide 43 text

Amazon EKS の採用について Q1. マイクロサービス化しているの？ A1. していません Q2. アクセス数が膨大だったりするの？ A2. まだまだ伸びしろあります（累計約 20万ユーザー）

Slide 44

Slide 44 text

Amazon Elastic Container Service (Amazon ECS) もじゅうぶん巨人ですけどね少人数のチームが（マイクロサービス化もしていないのに） Amazon EKS を採用する理由巨人（ = k8s エコシステム）の肩に乗る一度構築できてしまえば運用は大変ではない構築は Amazon EKS Blueprints for CDK がオススメ（次頁）

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

Amazon EKS のための Amazon CDK TIPS

Slide 47

Slide 47 text

Q. Cloud Formation で Infrastructure as Code は実現できるのではでしょうか？

Slide 48

Slide 48 text

たしかにそうですが、あれは YAML です。

Slide 49

Slide 49 text

AWS の構成管理を「コード」で行える https://github.com/aws/aws-cdk AWS Cloud Development Kit (CDK)

Slide 50

Slide 50 text

AWS CDK を使うことで YAML職人から脱却できる 50

Slide 51

Slide 51 text

AWS Cloud Development Kit (CDK)

Slide 52

Slide 52 text

とにかく依存関係が多い Amazon Virtual Private Cloud (Amazon VPC) Subnet groups, AWS Security Groups etc... 構築に20分程度はかかり試行錯誤が大変 AWS CDK + Amazon EKS つまづきポイント

Slide 53

Slide 53 text

AWS Cloud Development Kit (CDK) https://aws-quickstart.github.io/cdk-eks-blueprints/ Well-Architected な Amazon EKS クラスターを構築するための秘伝（？）のレシピが搭載されたライブラリ群

Slide 54

Slide 54 text

たったこれだけのコードで（※） Amazon VPC の設定にはじまり、ネットワークレイヤの設定を自動で行ったうえで Amazon EKS の構築を始めてくれる（！） ※ 実際はもうちょっと書きますが、全体で50行くらい

Slide 55

Slide 55 text

External Secrets Operator (ESO) や Argo CD など、 Kubernetes の運用に必要なサービスをあわせて導入できる豊富な Addon 55

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

Amazon EKS 構築 TIPS

Slide 58

Slide 58 text

AWS の構成管理を「コード」で行える https://github.com/aws/aws-cdk AWS Cloud Development Kit (CDK) Amazon EKS Blueprints その後 Amazon EKS のクラスタ構築後は、 Kubernetes Manifest を書こう AWS の関心事が関係する Manifest は仕様やバージョンに特に注意して進める

Slide 59

Slide 59 text

Elastic Load Balancing (ELB) / Application Load Balancer (ALB) は Ingress として定義する

Slide 60

Slide 60 text

Protocol Buffers / gRPC（再掲）インターフェースドリブンなシステム設計クライアント（Dart）、サーバー（Go）のコードの自動生成 alt-RESTFul API としてのナレッジを獲得するため選定の理由 60

Slide 61

Slide 61 text

AWS の構成管理を「コード」で行える https://github.com/aws/aws-cdk AWS Cloud Development Kit (CDK) gRPC を対象とする Web アプリを運用する場合、下記3つに注意 ALB 関連のオプションを gRPC 向けの内容にする ALB からのヘルスチェックにアプリ側で応答する Pod（コンテナ）内のヘルスチェックに対応する

Slide 62

Slide 62 text

ALB からのヘルスチェックにアプリ側で応答する ALB からのヘルスチェックにアプリ側で応答する定義したパス（サービス）で所定のレスポンスを返す https://github.com/grpc-ecosystem/grpc-health-probe grpc-health-probe の利用が便利

Slide 63

Slide 63 text

AWS の構成管理を「コード」で行える https://github.com/aws/aws-cdk AWS Cloud Development Kit (CDK) AWS Fargate 用の Deployment 1 Pod = 1 Fargate Node vCPUとメモリの値を指定

Slide 64

Slide 64 text

AWS の構成管理を「コード」で行える https://github.com/aws/aws-cdk AWS Cloud Development Kit (CDK) Amazon EKS on AWS Fargate 注意点 Daemon Set 未対応シークレット管理の選択肢が限られる Sidecar は対応してます AWS Graviton プロセッサ未対応対応に期待

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

Amazon EKS 運用 TIPS

Slide 67

Slide 67 text

AWS の構成管理を「コード」で行える https://github.com/aws/aws-cdk AWS Cloud Development Kit (CDK) RDB マイグレーションどこでやろう問題シークレット管理と並ぶ運用課題2大あるあるの1つ Pod の起動前に DBマイグレーションこっちも起動したから DBマイグレーション Replica set : 2

Slide 68

Slide 68 text

AWS の構成管理を「コード」で行える https://github.com/aws/aws-cdk AWS Cloud Development Kit (CDK)

Slide 69

Slide 69 text

AWS の構成管理を「コード」で行える https://github.com/aws/aws-cdk AWS Cloud Development Kit (CDK) Amazon EKS とDB マイグレーション Argo CD を使おう Manifest 運用を GitOps で遂行するための便利ツール https://argoproj.github.io/

Slide 70

Slide 70 text

Infrastructure as Code / Git Ops GitHub 上の差分を検知して Manifest を適用（SYNC) SYNC の前後に HOOK を仕込むことができるこの仕組みを利用して、 DB マイグレーションを実行する 70

Slide 71

Slide 71 text

移行プロジェクトの結果

Slide 72

Slide 72 text

AWS の構成管理を「コード」で行える https://github.com/aws/aws-cdk AWS Cloud Development Kit (CDK) 技術チーム約3名で、インフラ設計、バックエンド実装、データマイグレーションを遂行構想8ヶ月、実行半年もちろん課題や積み残しはあるものの、AWS 化計画を達成移行プロジェクトの結果

Slide 73

Slide 73 text

まとめ

Slide 74

Slide 74 text

なぜ "3年" なのかシードアーリーミドルレイター恐らく3年後には次の次のステージを（チームが）見据えているはずそのときまで事業をブーストできるインフラ基盤をいまつくる