DeepDive into Modern Development with AWS 2022/07/26 AWS事業本部コンサルティング部 ⾨別 優多 

2 自己紹介 門別 優多 – moko クラスメソッド株式会社 AWS事業本部コンサルティング部 入社: 2019/07 Twitter, GitHub: @mokocm 2019年7月〜2021年6月 コンサルティング部 2021年7月〜2022年6月 MAD事業部 2022年7月〜コンサルティング部 2020-2022 APN AWS Top Engineer 2021 APN ALL AWS Certifications Engineer 好きになったAWSサービス: App Runner 

3 「これだけは覚えて帰って欲しい」 せっかくクラウド使うなら クラウドらしい実装してくれ！！ 

4 本セッションの目的 エンジニアは本来集中するべき ビジネスロジックなどの実装に 工数を掛けて 気持ちよく（開発者体験よく） 開発して欲しい。 

5 本セッションの対象者 ・新規開発を検討中の方 ・新規開発中のエンジニアの方 ・最近の開発事情をおさらいしたい方 ・モダナイゼーションの参考 

6 本セッションの対象者 Web開発を基準にしてお話します。 その他のアプリケーションも応用のため 本セッションを聞いたら最近の技術選定 が分かります！ 

7 今日はなすこと 1. 最近の新規開発(Web)で使われる技術選定 2. これ使っとけアーキテクチャ3選 3. 開発フローとCI/CD 4. App Runnerのススメ 5. Demo 6. 超個人的な所感（まとめ） 

8 今日はなすこと 1. 最近の新規開発(Web)で使われる技術選定 2. これ使っとけアーキテクチャ3選 3. 開発フローとCI/CD 4. App Runnerのススメ 5. Demo 6. 超個人的な所感（まとめ） 

9 最近の新規開発で使われる技術選定 • Git • CI/CD • コンテナ • SPA (React, Vue, Next.js, Nuxt.js) (+ SSR, SSG, ISR) • OpenAPI • Serverless 

10 Git, CI/CD • 言わずもがなのバージョン管理 • まさか・・・Git使わないなんて無いよね・・・？ • GitとCI/CDはセットで初めに考える • GitHub + GitHub Actions • GitLab + GitLab Runner • BitBucket + BitBucket Pipelines • Any source + CodeBuild, CircleCIなど 

11 コンテナ • ローカル開発環境〜実行環境まで一元管理 • Dockerfileしっかり書けばローカルの環境構築時間を大幅に 短縮(git pull … docker-compose up) • Git, CI/CDとの親和性が高い、柔軟なデプロイ • ステートレスが大前提の設計に初めから意識して作ろうと 思える • などなど・・・ • AWSではECS, Fargate, EKS, AppRunner, Lambdaなどでコンテナ 実行可能 

12 とはいえ • ステートフルなアプリケーション、フレームワークの可能性もある • フレームワークの機能やPluginでステートレス化出来ないかを検討。 • ステートフルな箇所はManaged Serviceに寄せる • セッションをステートフルに保持するフレームワークの場合、最近のものは大半は Redis/memcachedなどに対応しているケースが多い。 • 例）Laravel, Spring, Express, Ruby on Railsなどなど、Redis/Memcached対応可能。 • アプリケーションの改修が出来ないケースではSticky Sessionが使えるかも • ALBが特定AZ障害時にSticky Sessionを利用していると巻きこまれるケースも。 • https://dev.classmethod.jp/articles/stateless_ec2/ • アプリケーションの特性上どうしてもステートフルなケース • 複数インスタンスの稼働が可能だが、ファイルを直書きしているケースEFSを活用してスケールアウト • EC2単体で動かす or Kubernetes StatefulSetを利用する • スケールアップよりも、スケールアウト出来るように改修する 

13 コンテナ化してください！！！ ※Serverless, SPAなどを除く 

14 よくあるフロント技術スタック Figma React TypeScript UI デザインツール ページ作成 コンポーネント作成 など フロントエンド フレームワーク 型がある JavaScript 

15 OpenAPI(Swagger) • API設計をYAML等で記述 • Git管理することによりバージョン管理 & Pull Requestでレビュー できる • Swaggerから言語の壁を越えて型を作成可能 • バックエンド、フロントと別ける場合などとても便利 • API 設計をExcelで作るのはやめよう 

AWS CDK • TypeScript, Python, Java, C#で記述可能なIaCツール • CloudFormationを出力。Serverlessの構成の場合はCDKでの デプロイが楽で良い 

17 もくじ 1. 最近の新規開発(Web)で使われる技術選定 2. これ使っとけアーキテクチャ3選 3. 開発フローとCI/CD 4. App Runnerのススメ 5. Demo 6. 個人的な所感（まとめ） 

18 1. ECS + RDSのベーシックな構成 

19 2. App Runner を利用した構成(ソースコードそのまま) Node.js 12, 14, Python3.7, 3.8 / Java8, 11 (2022/07/25時点) 

20 2. App Runner を利用した構成(コンテナ) 

21 2. App Runner を利用した構成(コンテナ) ref: https://dev.classmethod.jp/articles/re-introduction-2022-app-runner/ 

22 2. App Runner を利用した構成(コンテナ) https://dev.classmethod.jp/articles/re-introduction-2022-app-runner/ 

23 3. Serverless構成 (API Gateway + Lambda) 

AWS CDK /w Serverless TypeScript よくあるサーバーレス(backend)リポジトリ設計 • src/index.ts -> Lambdaのエントリーポイント • docs/openapi.yaml -> OpenAPI(Swagger)定義 • infrastrcture/ -> CDKの構成ファイル。 基本Lambdaのソースコード + CDKを同じリポジトリで管理する 

25 ざっくりアーキテクチャ選定フロー 

26 もくじ 1. 最近の新規開発(Web)で使われる技術選定 2. これ使っとけアーキテクチャ3選 3. 開発フローとCI/CD 4. App Runnerのススメ 5. Demo 6. 超個人的な所感（まとめ） 

27 Git branch strategy とりあえずはGitHub Flow。課題を感じたら他を検討 mainブランチはリリース可能な状態にする。 最新のコードはmainにあり、 main branchからfeatureが常に切れる状態。 一方で、GitFlowでよくあるdevelopブランチはdev環境、mainブランチは staging、releaseブランチはproductionなどの細かいブランチ単位での環 境デプロイが出来ない 

28 Tag Release 辿り着いたのはTag Release。 main branch： dev tagをpush： staging GitHubの「Release」機能でReleaseを作成：production 👍 Releaseでリリースノートを自動生成出来るので 変更差分が分かりやすい 👍 簡単操作でデプロイ 

29 Tag Release: Dev環境 

30 Tag Release: Staging環境 

31 Tag Release: Production環境 

32 IaCする箇所としない箇所 • ECS, Fargateの場合 • コンテナをIaCツールでbuild & deployする場合は同リポジトリ • コンテナデプロイを他の方法でやる場合は、コンテナ、タスク定 義をIaCツールで管理しないのも選択肢の1つ • App Runnerの場合 • Runtimeが対応していれば何も考えない • コンテナの場合はdocker build, docker pushをCI/CDで書く • Serverless(API Gateway)の場合 • CDKを利用してデプロイするため、Lambdaのコードと同じリポジ トリにCDKのコードを管理する 

33 コンテナの場合、ECRまで送りつける。 ECRにImageをPushなすればだいたいなんとかなる ECS(Fargate)：ECR -> CodePipeline -> CodeDeploy AppRunner: ECR -> ManagedDeploy 

34 もくじ 1. 最近の新規開発(Web)で使われる技術選定 2. これ使っとけアーキテクチャ3選 3. 開発フローとCI/CD 4. App Runnerのススメ 5. Demo 6. 超個人的な所感（まとめ） 

35 App Runnerはいいぞ！ 

36 コンテナさえPushしておけばOK 先程のTag Releaseを活用してECRにPushすれば、 それだけで本番ワークロードが完成する 👍1コンテナでどれくらいのリクエストを処理出来るか を確認するだけでスケーリングはOK 👍 VPCとの接続も出来るので、ECS, Fargateとほぼ 同等に扱える 👍クラスターの管理が不要になる 

37 適してるワークロード 適してるワークロード • インターネットから叩いて良いサービス • コンテナ1個で起動できるアプリケーション • 2vCPU, 4GBで起動できるアプリケーション 上記3個さえクリアしてれば だいたいのワークロードで実行出来ます！ 

AWS CDK w/ App Runner ECR 

39 しいていうなら 2vCPU, 4GBが最大 1コンテナあたりを大きめのリソースにする必要がある アプリケーションはECS, Fargateのほうが良さそう ECS, Fargate程の柔軟性が無い & コンテナは1個のみ ECS, Fargateのタスク定義のような細かい設定が出来ない nginx + appみたいな構成が取れない 

40 もくじ 1. 最近の新規開発(Web)で使われる技術選定 2. これ使っとけアーキテクチャ3選 3. 開発フローとCI/CD 4. App Runnerのススメ 5. Demo 6. 超個人的な所感（まとめ） 

41 デモ #1 App Runnerのデモ 

42 もくじ 1. 最近の新規開発(Web)で使われる技術選定 2. これ使っとけアーキテクチャ3選 3. 開発フローとCI/CD 4. App Runnerのススメ 5. Demo 6. 超個人的な所感（まとめ） 

43 超個人的な所感 • 新規開発なら負債も少ない状態なので早めにコンテナ化はやるべき • （※front(SPA), Serverlessなどコンテナ化不要なものを除く） • Git使ってないのはやめてくれ。 • 開発者体験だいじ。だいじ。だいじ。本当にだいじ。 • OpenAPI書こう • YAMLで書いてるとしんどい箇所があるので、プログラムで書けるようなフレ ームワークを使うと良い • スキーマファーストは正義。型生成で実装を楽にしよう • インターネットに露出するものはApp Runner使ってれば良い • インターネットに露出する層はApp Runnerを使うのが運用管理上一番楽だと感 じた。RDS, ElastiCacheなどのVPCリソースも普通に使える。 • コンテナインスタンスは2vCPU, 4Gをスケールするような設計のため、注意 • Microservice的なサービスとの繋ぎ込みはVPC接続 or SQSなどで繋ぐとよい 

44 超個人的な所感 • 一般的なアプリケーションを作るのであれば、極力ステートフルな箇 所はManaged Serviceに寄せる • 「データベース自前実装！」などでない限りは、ステートフルな箇所は Managed Serviceに寄せる(それがクラウドの最大のメリット) • Database (Aurora, RDS, DynamoDB, etc…) • Static storage (S3) • Cache store (ElastiCache(Redis, Memcached)) • 普通のアプリケーションを作るのであれば、ステートレスに作ろう • クラウドは柔軟にスケール出来る事が最大のメリット • もちろん「スケールアップ」も柔軟に出来るが、「スケールアウト」の方が瞬 時に行えて、運用管理上でも一番楽 

45 まとめ 

46 「これだけは覚えて帰って欲しい」 せっかくクラウド使うなら クラウドらしい実装してくれ！！ 

No content