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

初めてのAWSフルサーバーレス開発で困ったこととそこから得た知見

 初めてのAWSフルサーバーレス開発で困ったこととそこから得た知見

Serverless Meetup Japan Virtual #17 の登壇資料です。
https://serverless.connpass.com/event/205099/

B83a91887164b8b538ff4b20d24e4491?s=128

Yuji Ishibashi

March 03, 2021
Tweet

Transcript

  1. 初めてのAWSフルサーバーレス開発で 困ったこととそこから得た知見 1

  2. 自己紹介 石橋 勇二 Ishibashi Yuji @1484_yuji 2020年4月 入社(新卒エンジニア) 2021年1月 CX事業本部MADチーム

    神奈川県大和市在住 好きなAWSサービス:AWS CDK 筋トレ・サウナ・お肉・寿司 2
  3. 3 今日話すこと AWSのフルーサーバーレス開発を経験した(している)中で、 個人的に困ったこととそこから得た知見を共有します。 サーバーレス開発へのオンボーディング・新人エンジニアの育 成のフェーズにある方などに、役立つ知見を共有できれば幸い です。

  4. 4 アジェンダ • 背景 • 困ったこととそこから得た知見 ◦ プロジェクトへのオンボーディング ◦ サービス間の連携とデバッグ

    ◦ CDKスタックのデプロイ
  5. 5 背景 SBGift様 既存システムのリプレース案件 マイクロサービスアーキテクチャの フルサーバーレスアプリへの移行 既存のプロジェクトに1月からJOIN [参考] SBギフト「AWS Amplify

    Console + CDKを用いて短納期・少人数・フルリ モートで作る管理画面」 #devio_showcase
  6. 6 プロジェクトへのオンボーディング 困った点①

  7. 7 プロジェクトへのオンボーディング 把握しておくべき情報、準備するべきこと 顧客・自社の課題、開発の進捗、リリース計画 プロジェクトの管理情報(Backlog, wiki, MTGの運用など) 開発環境の構築、リポジトリの構成の把握 サーバーレス開発の考え方、利用するサービスの方針 AWS構成概略、アプリケーション設計思想の理解

    デプロイ要件の把握、実際の開発の流れの把握
  8. 8 プロジェクトへのオンボーディング マインドマップによる情報の整理

  9. 9 複雑な情報を整理できる 思考のプロセスが理解できる 全体像を把握することができる メリット

  10. 10 サービス間の連携とデバッグ 困った点②

  11. 11 今回のシステムのAWS構成図(一部) AWS CDK

  12. 12 今回のシステムのAWS構成図(一部) フロントエンド BFF サーバーサイド AWS CDK インフラ(IaC)

  13. 13 今回のシステムのAWS構成図(一部) フロントエンド BFF サーバーサイド AWS CDK インフラ(IaC) 機能に対するフルスタックな実装が可能

  14. 例) あるデータを取得してフロントの画面に表示する • Lambdaハンドラ・処理ロジックを書く • CDKでバックエンドのリソースを定義する ◦ API Gateway リソース、メソッド、マッピングテンプレート

    ◦ Lambda function • GraphQL Schemaの定義 • CDKでBFFのリソースを定義する ◦ AppSyncのリゾルバ(function)、データソース • Reactでフロントのコードを書く ◦ 必要なコンポーネントの作成 ◦ Apollo Clientを使ったGraphQLクエリ 14 実際の開発フロー CDK
  15. 例) あるデータを取得してフロントの画面に表示する • Lambdaハンドラ・処理ロジックを書く • CDKでバックエンドのリソースを定義する ◦ API Gateway リソース、メソッド、マッピングテンプレート

    ◦ Lambda function • GraphQL Schemaの定義 • CDKでBFFのリソースを定義する ◦ AppSyncのリゾルバ(function)、データソース • Reactでフロントのコードを書く ◦ 必要なコンポーネントの作成 ◦ Apollo Clientを使ったGraphQLクエリ 15 実際の開発フロー CDK デバッグ時にどこで エラーが起きているか 把握する力が大事 一つの機能実装でも 複数のサービスを利用
  16. 16 具体的な動作確認とデバッグ CDK • Lambdaコンソールからテストイベントを作成し、Lambda関数を実行

  17. 17 CDK • Lambdaコンソールからテストイベントを作成し、Lambda関数を実行 • API Gatewayコンソールからテストイベントを作成し、メソッドのテストを実行 具体的な動作確認とデバッグ

  18. 18 CDK • Lambdaコンソールからテストイベントを作成し、Lambda関数を実行 • API Gatewayコンソールからテストイベントを作成し、メソッドのテストを実行 • ローカルからcurlして、レスポンスとログを確認 (API

    Gatewayの認証を含む) 具体的な動作確認とデバッグ
  19. 19 CDK • Lambdaコンソールからテストイベントを作成し、Lambda関数を実行 • API Gatewayコンソールからテストイベントを作成し、メソッドのテストを実行 • ローカルからcurlして、レスポンスとログを確認 (API

    Gatewayの認証を含む) • AppSyncコンソールから、クエリを実行 具体的な動作確認とデバッグ
  20. 20 CDK • Lambdaコンソールからテストイベントを作成し、Lambda関数を実行 • API Gatewayコンソールからテストイベントを作成し、メソッドのテストを実行 • ローカルからcurlして、レスポンスとログを確認 (API

    Gatewayの認証を含む) • AppSyncコンソールから、クエリを実行 • クライアント側からのリクエストとレスポンスの確認 具体的な動作確認とデバッグ
  21. 21 CDK • Lambdaコンソールからテストイベントを作成し、Lambda関数を実行 • API Gatewayコンソールからテストイベントを作成し、メソッドのテストを実行 • ローカルからcurlして、レスポンスとログを確認 (API

    Gatewayの認証を含む) • AppSyncコンソールから、クエリを実行 • クライアント側(Apollo Client)からのリクエストとレスポンスの確認 具体的な動作確認とデバッグ
  22. 22 AppSync リゾルバ データソースに対するリクエスト・レスポンスの処理を記 述する関数 リクエストマッピングテンプレートとレスポンスマッピング テンプレートで構成 パイプラインリゾルバ 複数のリゾルバを関数として束ねて実行できるリゾゾル バ

  23. 23 AppSyncコンソールでのデバッグ パイプラインリゾルバが設定された Queryを実行

  24. 24 パイプラインリゾルバのデバッグ パイプラインリゾルバが設定された Queryを実行

  25. 25 パイプラインリゾルバのデバッグ パイプラインリゾルバが設定された Queryを実行 CloudWatch Logsでログの確認が可能

  26. 26 パイプラインリゾルバのデバッグ 詳細なログモニタリングの設定 https://docs.aws.amazon.com/ja_jp/appsync/latest/devguide/monitoring.html#cwl

  27. 27 パイプラインリゾルバのデバッグ 詳細なログモニタリングの設定 リクエストレベルログ、フィールドレベルログ

  28. 28 CDKスタックのデプロイ 困った点③

  29. 29 開発におけるデプロイ戦略 ITG ステージ バックエンド動作確認用 手元から直接デプロイ可 CodePipeline DEV ステージ フロントの開発の際利用する環境

    パイプライン経由でのデプロイ
  30. 30 ある日行った作業 CDK • フロント側で扱いたいデータを整理 • 既存のクエリにアタッチされたパイプラインリゾルバ • ユニットリゾルバで十分データを取得できる •

    パイプラインリゾルバの削除、ユニットリゾルバを作成
  31. 31 想定していた挙動 ・パイプラインリゾルバの記述を削除 ・ユニットリゾルバの記述を追加 cdk deploy クエリ データソース データソース パイプラインリ

    ゾルバ データソース ユニット リゾルバ クエリ 変更
  32. 32 上書きに失敗 ・パイプラインリゾルバの記述を削除 ・ユニットリゾルバの記述を追加 cdk deploy クエリ データソース データソース パイプラインリ

    ゾルバ データソース ユニット リゾルバ クエリ リソースの上書き(削除・作成)に 失敗する
  33. 33 AppSyncのCDKコンストラクタ cdk-constructsはEXPERIMENTAL https://docs.aws.amazon.com/cdk/api/latest/docs/aws-appsync-readme.html

  34. 34 対応措置 ・パイプラインリゾルバの記述を削除 cdk deploy クエリ データソース データソース パイプラインリ ゾルバ

    データソース ユニット リゾルバ クエリ ・ユニットリゾルバの記述を追加 cdk deploy 削除 作成 ① ②
  35. 35 開発におけるデプロイ戦略 ITG ステージ バックエンド動作確認用 手元から直接デプロイ可 DEV ステージ フロントの開発等で利用する環境 パイプライン経由でのデプロイ

    CodePipeline 対応措置 push
  36. 36 開発におけるデプロイ戦略 ITG ステージ バックエンド動作確認用 手元から直接デプロイ可 DEV ステージ フロントの開発等で利用する環境 パイプライン経由でのデプロイ

    CodePipeline 対応措置 通常のデプロイ
  37. 37 開発におけるデプロイ戦略 ITG ステージ バックエンド動作確認用 手元から直接デプロイ可 DEV ステージ フロントの開発等で利用する環境 パイプライン経由でのデプロイ

    CodePipeline 対応措置 通常のデプロイ
  38. 38 わかったこと • EXPERIMENTALのコンストラクタは、挙動の確認が必要。 ◦ Low Level コンストラクタ(CFN-)の利用も 【AWS CDK】CDK標準の3種類のConstructを使って、AWSリソースをデプロイしてみた

    • stg/prodなどの環境のCI/CDパイプラインには、   承認 アクションがあったほうがベター。 ◦ 継続的デリバリーか、継続的デプロイメントか。
  39. 39 まとめ • 案件情報の整理にマインドマップが便利だった • サービス内のコンポーネント・サービス間の連携を把握してデ バッグできると開発のスピードが上がる • CDKのデプロイに際して、コンストラクタの挙動確認・選定が 必要になることも

  40. 40