AWS Summit Japan 2025 Community Stage - App workflow automation by AWS Step Functions

Transcript

1. AWS Step Functions で挑む アプリケーションワークフロー自動化 Hidetoshi Matsui Cyber Security Cloud / Generative Technology AWS Serverless Hero AWS Summit Japan 2025 Community Stage
2. 自己紹介
3. 自己紹介 松井 英俊 株式会社ジェネレーティブテクノロジー　マネージャー　兼 株式会社サイバーセキュリティクラウド　クラウドエバンジェリスト AWS Serverless Hero
4. 日本のAWSのコミュニティであるJAWS-UGの支部 （浜松の地域支部・メディア関連の専門支部）の 運営に携わっております。 オンラインイベントでの独自の配信基盤構築や、 それに伴う登壇やブログ等のアウトプットにも 力を入れています。 コミュニティ参加・運営 コロナ禍の市民活動として、コロナ対策サイトの 浜松市版や飲食店のテイクアウト・デリバリー まとめサイトなどをAWSを活用して 構築・公開してきました。 シビックテック コミュニティに関わる取り組み
5. それまでの取り組みを評価され2021年よりAWS Serverless Heroに選ばれました。 AWS Heroとは: ‘ AWS ヒーロープログラムは、熱心なナレッジ共有によってコミュニティに大きな影響 を与えている世界中の精力的な AWS エキスパートの皆さんを表彰します。ヒーロー は、ソーシャルメディア、ブログ投稿、オープンソースプロジェクト、動画、フォーラ ムを介してオンラインで、または会議、ワークショップ、ユーザーグループイベントで 直接会うなど、さまざまな方法で知識を共有します。’ - AWS公式サイトより AWS Hero として コミュニティに関わる取り組み
6. 毎年開催されるAWS Summit Japan、AWS re:Invent、AWS Heroes Summitや コミュニティ主催のイベント: JAWS DAYSなどで、それまでに得られた知見や コミュニティ活動における成功体験などについてアウトプットしています。 AWS公式Webマガジン: builders.flashにも定期的に記事を寄稿しています。 近年はAWSを活用した配信基盤構築で得た知見に基づき Amazon IVS(Interactive Video Service)サービスチームと連携をと、 コミュニティ活動を通じたプロトタイプ構築やサービスへの フィードバック等の取り組みも実施しています。 AWS Hero として コミュニティに関わる取り組み
7. 立ち上げ期のスタートアップから始まり、地方（浜松）の小規模なSIや Web制作会社等でのWebアプリケーション開発を経験し、現職の受託開発事業に至ります。 プログラミングスクール講師の経験も。 Webアプリケーション開発者として 主にAWSを用いてWebアプリケーションとそれに付随するワークフロー等の クラウド構築をしてきました。 クラウドアーキテクトとして エンジニアとしての経験に基づき、顧客のビジネスに対する新規開発や アーキテクチャ改善・コスト最適化等の提案をしています。 営業やプリセールス 自社や顧客のエンジニア育成やマネジメントをしています。 マネジメント 仕事として取り組んでいること
8. 今日の内容
9. • そもそも Web アプリケーションにはどんな要素が必要か？の整理 • クラウド（AWS）の利用を前提とした時に考慮するべきことは？ • 実際に今まで私が設計・構築してきたクラウドアーキテクチャの紹介 • AWS Step Functions を使ったワークフロー自動化の実践的なアイデアの紹介 • これらに付随するサンプルコード 話すこと 話さないこと（やらないこと） 今日の内容 • 具体的な Step by step の構築方法の説明 • そのまま利用できるような IaC コードまたは自動化スクリプト等の紹介
10. そもそも Web アプリケーションには どんな要素が必要か？
11. 思いつく限り挙げてみてください
12. およそ考えられる要素
13. およそ考えられる要素 • 「サーバー立てれば終わり」じゃない • 付随するワークフローが様々ある ◦ デプロイ自動化 ◦ スケーリング ◦ スケジュール実行 ◦ 踏み台サーバー ◦ etc.
14. どうやって実現するか？
15. 究極系
16. 究極系 • （お気づきの通り）クラウド環境を 最適化した形ではない • ただしこれが絶対にNGという わけでもない
17. クラウド（AWS）の利用を 前提とした時に考慮すべきことは？
18. AWS Well-Architected と 6 つの柱 • オペレーショナルエクセレンスの柱 • セキュリティの柱 • 信頼性の柱 • パフォーマンス効率の柱 • コスト最適化の柱 • 持続可能性の柱 AWS Well-Architected と 6 つの柱 https://aws.amazon.com/jp/architecture/well-architected より
19. 先ほどの構成の問題点 • 運用上非効率なポイントが多い • セキュリティ境界が適切に 分離できない • 信頼性の担保が難しい • パフォーマンス向上に障壁がある • コスト最適化が困難 • サービスの持続性や環境負荷にも 問題あり
20. 改めて、クラウド（AWS）の利用を 前提とした時に考慮すべきことは？
21. オンプレミスとクラウドの違い
22. オンプレミスとクラウドの違い オンプレミス : 初期投資＋運用コスト クラウド : 使った分だけ支払う従量課金 → 使った分だけ支払うような 　 使い方をする必要がある ※一般的な傾向として
23. 考慮すべきこと
24. 運用が自動化されているか？ • 手動で実施する必要性のないオペレーション（トイル）がないか？ ◦ アプリケーションの変更のリリース ◦ データベースのスキーマ変更 ◦ 異常検知 ◦ リトライ ◦ etc.
25. セキュリティが考慮されているか？ • 不要だったり、工夫により無くせるリソースはないか？ • ネットワーク設計が適切か？（不要な露出はないか？） • 設定項目に不備はないか？ • セキュリティサービスが適切に導入・有効化されているか？
26. 信頼性が担保されているか？ • 必要な信頼性が定義できているか？ • AZ などを跨いだ耐障害性が考慮されているか？ • 柔軟にスケーリングするか？ • 実行確実性が考慮されているか？ • 失敗のリカバリが考慮されているか？ • サービスレベルの掛け合わせを考慮できているか？
27. 必要なパフォーマンスを発揮できるか？ • 必要なパフォーマンスが定義できているか？ • 必要なパフォーマンスを実現するのに合理的な サービス・構成の設定ができているか？ • パフォーマンスを考慮した データの読み書きの仕組みになっているか？ • 通信経路に非効率な箇所はないか？
28. コスト最適化が図られているか？ • 可能な限り Pay-as-you-go なコスト体系か？ • コスト最適化できるアーキテクチャか？ ◦ オートスケーリングする ◦ 変更が容易 ◦ 適切な責務の分離 Amazon CTO Werner Vogels 氏による Keynote の様子 - AWS re:Invent 2023 にて
29. 持続可能なアーキテクチャになっているか？ • スケールにより際限なくコストが上がらないか？ • スケールするほど割安になっているか？ • 蓄積して増えるコストがないか？ • 本当に必要なリソースやデータに絞れているか？
30. 今まで設計・構築してきた アーキテクチャの例
31. アーキテクチャ例 ※本筋ではない箇所は省略
32. 考慮しているポイント • スケーラブル • 個別にスケーリング・サイジング • 実行確実性を考慮 • ワークフローを自動化 • （極力）サーバーレス • ノー（ロー）コード • 適切なネットワーク境界
33. AWS Step Functions を使った ワークフロー自動化の 実践的なアイデアの紹介
34. その前に AWS Step Functions の良いところ
35. AWS Step Functions とは • 2016年 正式リリース • 2021年 200以上のサービス、 9000以上のAPIをサポート （現在はさらに増えている） • ワークフローを視覚的に構築 • 分散処理が可能 • サーバーレス
36. Step Functions の良いところ: サーバーレス • Pay-as-you-go な料金体系 • スケーリングやサイジングを考えなくて良い • 占有するリソースを作らなくて良いので セキュリティホールを作るリスクが小さい
37. Step Functions の良いところ: ノーコード • 多様な組み込み関数と API 統合により ノーコードでワークフローを実装可能 • アプリケーションコードのメンテナンスが不要 • ランタイムメンテナンスが不要
38. Step Functions の良いところ: 様々な API 呼び出し • 220以上のサービス、14,000以上のAPI呼び出しが できる • AWS SDK Service Integrationsを利用 • 多くのパターンで AWS 内部 API コールの ためだけの AWS Lambda 関数作成を省略できる
39. Step Functions の良いところ: 並列・長時間実行 • Lambda の15分のような短い制限がなく 標準ワークフローでは最大1year • 大規模なデータ分散処理にも利用可能
40. 高度なマネージドサービスとの向き合い方 （≒ トレードオフを認識しておく） • AWS Step Functions のようなものはおよそ他のサービスには 簡単にリプレイスはできない • マネージドサービス ≒ ロックインと引き換えに便利さを享受している • ポータビリティの必要性と簡便さを天秤にかけて考える
41. 具体的なアイデアの紹介
42. スケジュール実行
43. スケジュール実行
44. スケジュール実行
45. スケジュール実行 • ECS の組み込み機能の「スケジュールされたタスク」では リトライ等考慮されない簡易的な呼び出しのみ • AWS Step Functions を利用することで RunTask 失敗時の エラー処理としてリトライや通知などを柔軟に組み込み可能 • 実行確実性が求められるケースにおいて容易に導入できる
46. デプロイ前後処理
47. デプロイ前後処理
48. パイプライン全体像 • OIDC 認証により GitHub Actions から AWS リソースを操作 （Amazon Elastic Container Registry, S3） • AWS CodePipeline でデプロイメント パイプラインを実行 • パイプラインから Step Functions を 呼び出し付随する処理を実行
49. デプロイ前処理（データベーススキーマ変更処理） • ECS RunTask 呼び出しを Lambda 等を使用せず直接実行 • IntegrationPattern: RunJob を選択することで タスクの Exit code を判定 → 成功・失敗に応じて後続処理への移行を制御し 失敗したらデプロイを自動で中断することが可能 • AWS CodeBuild 等を使用するパターンと比較し少ないコード量で実現
50. 参考: CDK のサンプル - ステートマシン作成 RunTask で作成するタスク用の セキュリティグループ作成 サブネットグループの取得 RunTask ステートの作成 Construct ライブラリがあるが コンテキストなどの詳細パラメータの 調整が必要な場合はカスタムステートで Fail ステートの作成 Fail でステートマシンが終了した場合 CodePipeline パイプラインにも失敗を自動で通知 Fail ステートを RunTask ステートに関連づけ 作ったステートを使用して ステートマシン作成 ←重要
51. 参考: Step Functions Invoke Action 作成 ステートマシンを指定して CodePipeline アクションを作成 アクションを指定し パイプラインにステージを追加
52. デプロイ後処理 • SDK Intagrations は Amplify:StartJob API にも対応しており バックエンドのデプロイ完了を保証してからフロントエンドを更新するような フローも実現可能 • 対応 API : https://docs.aws.amazon.com/step-functions/latest/dg/supported-services-awssdk.html
53. 参考: SDK Integrations の CDK での書き方 • CallAwsService Construct を呼び出す • service, action と必要に応じて parameters, iamResources を指定する • 詳細: https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_stepfunctions_tasks.Call AwsService.html
54. 踏み台 ECS タスク構築
55. 踏み台 ECS タスク構築
56. 踏み台 ECS タスク構築
57. 踏み台 ECS タスク構築 • ネットワーク的開口部を作る必要がない • 必要な時だけタスクを起動 • 開発者の権限を最低限に絞ることができる • シェルスクリプトなどの工夫により開発者が内部構造の 詳細を知らなくても簡単に接続可能
58. まとめ • アプリケーションに付随するワークフローのサーバーレス自動化を目指そう • サーバーレス化で Well-Architected にしよう • Step Functions の活用で AWS 内部の API コールやワークフロー実装の 「とりあえず Lambda」から卒業しよう • Step Functions でエラーハンドリングし実行確実性を向上させよう • AWS 上のほとんどの API を Step Functions から呼び出し可能 • IaC(CDK) でのステートマシン管理にも挑戦してみよう
59. 質問・提案歓迎です • コミュニティ Slack やイベントでお声掛けください！ • もっと良い方法があったら、コミュニティでぜひシェアしてください！
60. Thank you! 松井 英俊 Hidetoshi Matsui @hide04241990 https://www.linkedin.com/in/hidetoshi-matsui https://github.com/matsuihidetoshi