Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DeepDive into Modern Development with AWS

mokonist
August 01, 2022

DeepDive into Modern Development with AWS

mokonist

August 01, 2022
Tweet

More Decks by mokonist

Other Decks in Technology

Transcript

  1. 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
  2. 9 最近の新規開発で使われる技術選定 • Git • CI/CD • コンテナ • SPA

    (React, Vue, Next.js, Nuxt.js) (+ SSR, SSG, ISR) • OpenAPI • Serverless
  3. 10 Git, CI/CD • 言わずもがなのバージョン管理 • まさか・・・Git使わないなんて無いよね・・・? • GitとCI/CDはセットで初めに考える •

    GitHub + GitHub Actions • GitLab + GitLab Runner • BitBucket + BitBucket Pipelines • Any source + CodeBuild, CircleCIなど
  4. 11 コンテナ • ローカル開発環境〜実行環境まで一元管理 • Dockerfileしっかり書けばローカルの環境構築時間を大幅に 短縮(git pull … docker-compose

    up) • Git, CI/CDとの親和性が高い、柔軟なデプロイ • ステートレスが大前提の設計に初めから意識して作ろうと 思える • などなど・・・ • AWSではECS, Fargate, EKS, AppRunner, Lambdaなどでコンテナ 実行可能
  5. 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を利用する • スケールアップよりも、スケールアウト出来るように改修する
  6. 15 OpenAPI(Swagger) • API設計をYAML等で記述 • Git管理することによりバージョン管理 & Pull Requestでレビュー できる

    • Swaggerから言語の壁を越えて型を作成可能 • バックエンド、フロントと別ける場合などとても便利 • API 設計をExcelで作るのはやめよう
  7. AWS CDK /w Serverless TypeScript よくあるサーバーレス(backend)リポジトリ設計 • src/index.ts -> Lambdaのエントリーポイント

    • docs/openapi.yaml -> OpenAPI(Swagger)定義 • infrastrcture/ -> CDKの構成ファイル。 基本Lambdaのソースコード + CDKを同じリポジトリで管理する
  8. 27 Git branch strategy とりあえずはGitHub Flow。課題を感じたら他を検討 mainブランチはリリース可能な状態にする。 最新のコードはmainにあり、 main branchからfeatureが常に切れる状態。

    一方で、GitFlowでよくあるdevelopブランチはdev環境、mainブランチは staging、releaseブランチはproductionなどの細かいブランチ単位での環 境デプロイが出来ない
  9. 28 Tag Release 辿り着いたのはTag Release。 main branch: dev tagをpush: staging

    GitHubの「Release」機能でReleaseを作成:production 👍 Releaseでリリースノートを自動生成出来るので 変更差分が分かりやすい 👍 簡単操作でデプロイ
  10. 32 IaCする箇所としない箇所 • ECS, Fargateの場合 • コンテナをIaCツールでbuild & deployする場合は同リポジトリ •

    コンテナデプロイを他の方法でやる場合は、コンテナ、タスク定 義をIaCツールで管理しないのも選択肢の1つ • App Runnerの場合 • Runtimeが対応していれば何も考えない • コンテナの場合はdocker build, docker pushをCI/CDで書く • Serverless(API Gateway)の場合 • CDKを利用してデプロイするため、Lambdaのコードと同じリポジ トリにCDKのコードを管理する
  11. 43 超個人的な所感 • 新規開発なら負債も少ない状態なので早めにコンテナ化はやるべき • (※front(SPA), Serverlessなどコンテナ化不要なものを除く) • Git使ってないのはやめてくれ。 •

    開発者体験だいじ。だいじ。だいじ。本当にだいじ。 • OpenAPI書こう • YAMLで書いてるとしんどい箇所があるので、プログラムで書けるようなフレ ームワークを使うと良い • スキーマファーストは正義。型生成で実装を楽にしよう • インターネットに露出するものはApp Runner使ってれば良い • インターネットに露出する層はApp Runnerを使うのが運用管理上一番楽だと感 じた。RDS, ElastiCacheなどのVPCリソースも普通に使える。 • コンテナインスタンスは2vCPU, 4Gをスケールするような設計のため、注意 • Microservice的なサービスとの繋ぎ込みはVPC接続 or SQSなどで繋ぐとよい
  12. 44 超個人的な所感 • 一般的なアプリケーションを作るのであれば、極力ステートフルな箇 所はManaged Serviceに寄せる • 「データベース自前実装!」などでない限りは、ステートフルな箇所は Managed Serviceに寄せる(それがクラウドの最大のメリット)

    • Database (Aurora, RDS, DynamoDB, etc…) • Static storage (S3) • Cache store (ElastiCache(Redis, Memcached)) • 普通のアプリケーションを作るのであれば、ステートレスに作ろう • クラウドは柔軟にスケール出来る事が最大のメリット • もちろん「スケールアップ」も柔軟に出来るが、「スケールアウト」の方が瞬 時に行えて、運用管理上でも一番楽