大規模サーバーレスAPIの堅牢性・信頼性設計 〜AWSのベストプラクティスから始まる現実的制約との向き合い方〜

2025/10/11 JAWS FESTA 2025 in 金沢
https://jawsfesta2025.jaws-ug.jp/sessions/timetable/85/

Transcript

1. ©Fusic Co., Ltd. 0 大規模サーバーレスAPIの堅牢性・信頼性設計 〜AWSのベストプラクティスから始まる現実的制約との向き合い方〜 2025.10.11 Mai Miyazaki @maimyyym JAWS FESTA 2025 in 金沢
2. ©Fusic Co., Ltd. 1 Introduction 宮 崎 真 衣 M A I M I YA Z A K I HN: mai (@maimyyym ) 株式会社Fusic 事業本部 クラウドエンジニアリング部門 チームリーダー / エンジニア ◉ I am - IDDM(1型糖尿病) 3歳発症 - 元百貨店スタッフ（Beauty Counselor） - 2023年10月 Fusic入社 ◉ Skill - AWS / Python / TypeScript / PHP(Laravel) - Interested in: Security, Identity & Compliance ◉ Comment - はじめての北陸！ Click!!
3. ©Fusic Co., Ltd. 2 お話すること 金沢だからこそ 題材：多くのアクセスを捌く かつ 予期しないスパイクがあるシステム 一つのベストプラクティスだけが絶対解ではない JAWSをはじめ、多くの勉強会で広げた知見があったからやってこれた そんな経験をこの場で共有します
4. ©Fusic Co., Ltd. 3 CONTENTS 目次 1. 題材となるシステムの紹介 2. 絡み合う制約 3. 包括的な信頼性設計へ 4. 解に至るまで
5. ©Fusic Co., Ltd. 4 題材となるシステムの紹介 システムアーキテクチャ / 求められていたこと 1
6. ©Fusic Co., Ltd. 5 システムのアーキテクチャ紹介 題材となるシステムの紹介 ▪ プライベートAPI Gateway → Lambda → OpenSearchがAPIの基本構成 ▪ OpenSearchにデータを格納する機構もサーバーレスで構築 ▪ サーバーレスだが、考える範囲は非常に多い
7. ©Fusic Co., Ltd. 6 求められていたこと 題材となるシステムの紹介 セキュリティ要件 ▪ データの適切な保護 ▪ 基準はAWSのベストプラクティス • 検知の仕組みがすでにある 性能要件 ▪ P90で200〜500ms以下 ▪ エラー率0.01%未満 ▪ イレギュラーなピーク時にも落ちないこと ▪ リクエストは数十〜数百RPS 変更できない スケジュール要件 安定稼働のための 運用・監視体制
8. ©Fusic Co., Ltd. 7 絡み合う制約 2つのスタートから始まる技術検証・意思決定 2
9. ©Fusic Co., Ltd. 8 二つのスタート 絡み合う制約 Amazon OpenSearch ServiceをVPC内に置くこと AWS Foundational Security Best Practices (FSBP) standard の、 [Opensearch.2] OpenSearch ドメインがパブリックにアクセスできないように する必要があります というコントロールへの対応 01 Amazon OpenSearch ServiceのServerless移行 PoC段階から動かしていたAmazon OpenSearch Serviceを 性能要件を受けてスパイク対策のためにAmazon OpenSearch Serverless に移行を検討 02
10. ©Fusic Co., Ltd. 9 二つのスタート 絡み合う制約 Amazon OpenSearch ServiceをVPC内に置くこと AWS Foundational Security Best Practices (FSBP) standard の、 [Opensearch.2] OpenSearch ドメインがパブリックにアクセスできないように する必要があります というコントロールへの対応 01 Amazon OpenSearch ServiceのServerless移行 PoC段階から動かしていたAmazon OpenSearch Serviceを 性能要件を受けてスパイク対策のためにAmazon OpenSearch Serverless に移行を検討 02 Critical
11. ©Fusic Co., Ltd. 10 OpenSearchをVPCに置く影響 OpenSearch private化の検討 Lambda関数のVPCアタッチ OpenSearchダッシュボード 利用のための踏み台EC2構築
12. ©Fusic Co., Ltd. 11 OpenSearchをVPCに置く影響 OpenSearch private化の検討 Lambda関数のVPCアタッチ OpenSearchダッシュボード 利用のための踏み台EC2構築
13. ©Fusic Co., Ltd. 12 Lambda VPCアタッチの影響 OpenSearch private化の検討 気になるのは性能への影響 - コールドスタートは意外と大きな問題ではなかった - 2019年のアップデートで大幅に改善されていた - 実測したところ、差はあまりない(むしろ速い) 非VPC VPCアタッチ Init 3.42s Init 2.51s ※その他対策も重ね、今は100ms以下になっています
14. ©Fusic Co., Ltd. 13 Lambda VPCアタッチの影響 OpenSearch private化の検討 気になるのは性能への影響 - アプリケーションメトリクスの外部送信レイテンシ - 監視要件で避けられない - NAT Gatewayを配置する必要がある 高トラフィック ＝転送するメトリクス量は膨大 ＝コストへの影響 Lambda実行時間 への懸念 検証しないと見えない + 複数チームの連携が必須 大規模プロジェクトだからこそ 技術的意思決定のための 検証コスト・スケジュール制約が発生
15. ©Fusic Co., Ltd. 14 OpenSearchをVPCに置く影響 OpenSearch private化の検討 Lambda関数のVPCアタッチ OpenSearchダッシュボード 利用のための踏み台EC2構築
16. ©Fusic Co., Ltd. 15 VPC内OpenSearchダッシュボードアクセス OpenSearch private化の検討 [前提] VPC外のOpenSearchダッシュボードはパブリックにアクセス可能 ※認証 / IP制限の実装可
17. ©Fusic Co., Ltd. 16 VPC内OpenSearchダッシュボードアクセス OpenSearch private化の検討 VPC内OpenSearchの場合、踏み台サーバーが必要に • 体感として通信速度が遅い • セッションが切れると再接続 • EC2の管理コスト・セキュリティ対策 運用コストの増大 検証してみた
18. ©Fusic Co., Ltd. 17 OpenSearchをVPCに置くことは… OpenSearch private化の検討 選ばなかった 監視 要件 NAT Gatewayを置く 運用に必要なダッシュボード へのアクセスがEC2経由に Lambda実行時間の増加 → 性能面への懸念 転送量が過多 → 料金コストの懸念 EC2の構築・運用コスト セキュリティ面の考慮ポイント増加
19. ©Fusic Co., Ltd. 18 OpenSearchをVPCに置くことは… OpenSearch private化の検討 選ばなかった 監視 要件 NAT Gatewayを置く 運用に必要なダッシュボード へのアクセスがEC2経由に Lambda実行時間の増加 → 性能面への懸念 転送量が過多 → 料金コストの懸念 EC2の構築・運用コスト セキュリティ面の考慮ポイント増加 〜 絡み合う制約 〜 残る課題は…セキュリティ
20. ©Fusic Co., Ltd. 19 二つのスタート 絡み合う制約 Amazon OpenSearch ServiceをVPC内に置くこと AWS Foundational Security Best Practices (FSBP) standardの、 [Opensearch.2] OpenSearch ドメインがパブリックにアクセスできないように する必要があります というコントロールへの対応 01 Amazon OpenSearch ServiceのServerless移行 PoC段階から動かしていたAmazon OpenSearch Serviceを 性能要件を受けてスパイク対策のためにAmazon OpenSearch Serverless に移行を検討 02
21. ©Fusic Co., Ltd. 20 Serverless化は… Amazon OpenSearch Serverlessへの移行検討 目的 スパイク対策
22. ©Fusic Co., Ltd. 21 Serverless化は…選べなかった Amazon OpenSearch Serverlessへの移行検討 ◼ IP制限 ◼ 複数ベンダー・チームのユーザー管理 期待するアクセス制御ができない ◼ 必須のプラグインを使えない ◼ 必須のAPIがサポートされていない そもそもシステム要件を満たせない 目的 スパイク対策
23. ©Fusic Co., Ltd. 22 Serverless化は…選べなかった Amazon OpenSearch Serverlessへの移行検討 ◼ IP制限 ◼ 複数ベンダー・チームのユーザー管理 期待するアクセス制御ができない ◼ 必須のプラグインを使えない ◼ 必須のAPIがサポートされていない そもそもシステム要件を満たせない 残る課題は・・・ スパイク対策
24. ©Fusic Co., Ltd. 23 包括的な信頼性設計へ 守りたかったベストプラクティスから、多層的なベストプラクティスの実装へ 考慮レイヤーがシンプルになる効果 3
25. ©Fusic Co., Ltd. 24 守りたかった、ベストプラクティス 包括的な信頼性設計へ “AWSのベストプラクティス” クラウドを利用する上で、準拠したい なぜなら、これを守ることが安定運用につながるから。 とくにセキュリティ標準のCriticalな事項に従わない選択は苦しい
26. ©Fusic Co., Ltd. 25 多層的に実装するベストプラクティス 包括的な信頼性設計へ セキュリティ検知の運用において、「Supress(抑制)」という選択がある 特定のアラートを無視するための選択肢 個人的な見解として、「抑制できる」という意味を感じる
27. ©Fusic Co., Ltd. 26 多層的に実装するベストプラクティス 包括的な信頼性設計へ OpenSearchへのアクセスを絞る • リソースポリシーでLambda実行ロールのみ許可 • インデックス操作をOpenSearch内部でも絞る 最小権限の徹底 • OpenSearch 監査ログの出力 追跡可能性 • CloudWatchアラーム → 通知機構の構築 • CloudWatchダッシュボード構築 • 実測に基づくインスタンスタイプ等の値決定 監視→スケーリング運用 すごく時間がかかるものではない 最初にやればいいだけ、後から楽できるもの そんな、一つ一つはとても小さくて細かな 設定作業を積み重ね、Criticalを抑制した
28. ©Fusic Co., Ltd. 27 考慮レイヤーがシンプルになる効果 包括的な信頼性設計へ 実際にサービスインして・・・ 大規模トラフィックを捌くため、高負荷・高レイテンシ時の原因調査が多々発生 どこがボトルネックか？をレイヤーごとに追跡していくため、 OpenSearchをVPCに置かないことで考慮レイヤーがよりシンプルに この選択が正解だったと言える
29. ©Fusic Co., Ltd. 28 考慮レイヤーがシンプルになる効果 包括的な信頼性設計へ 実際にサービスインして・・・ サーバーレス・オートスケールだけに頼れない、人間による判断の必要性 運用開始後のパフォーマンス改善のためのメトリクス追跡
30. ©Fusic Co., Ltd. 29 考慮レイヤーがシンプルになる効果 包括的な信頼性設計へ 実際にサービスインして・・・ サーバーレス・オートスケールだけに頼れない、人間による判断の必要性 運用開始後のパフォーマンス改善のためのメトリクス追跡 CloudWatchダッシュボードが大活躍！ ・API Gateway: Count, 5xxError, Latency ・Lambda: Invocations, Throttles, Duration, ProvisionedConcurrentExecutions ・OpenSearch: CPUUtilization, JVMMemoryPressure, SearchLatency ※中身は隠してお届けします。 実際はとってもおもしろい！ 手動スケール の判断材料に
31. ©Fusic Co., Ltd. 30 解に至るまで 大規模サーバーレスだからこそ / 考えていたこと 4
32. ©Fusic Co., Ltd. 31 大規模サーバーレスだからこそ 解に至るまで サーバーレスだからこそ・・・ • サーバーの管理・運用がAWSマネージドだからこそ、限界への挑戦が起こりうる • AWSマネージドにできるからこそ、求められるさまざまな要件に対して向き合い、 考えることにエネルギーを使える
33. ©Fusic Co., Ltd. 32 何を考えていたか 解に至るまで 大規模システムでの技術的意思決定の勘所 • システムの意義は何か。 そこから「何をやらず、その代わりにどうするか。」選択肢を積み上げていく。 • セキュリティ・性能があった上での安定稼働・運用。 スケジュール・リソースの中で、焦らず構築していくこと。 • 見えない部分も含めた全体最適。 何を求められているか、を汲み取るコミュニケーション。
34. ©Fusic Co., Ltd. 33 何を考えていたか 解に至るまで 一つのベストプラクティスを守ることだけが絶対解ではない ・・・という解に至るまで。 幅広い知恵を掻き集めるように、フル回転した。 社内の集合知の活用 勉強会参加で脳内に作られた 知識のインデックス ※絶対に守りましょうという話でも、守らなくてもいいという話でもない
35. ©Fusic Co., Ltd. 34 学び得た、大切なこと 大規模サーバーレスAPIの堅牢性・信頼性設計 多層的なベストプラクティスを実装し、考慮レイヤーを減らしていくこと Point 01 システムの意義を考え、安定稼働・運用のためのセキュリティ要件・性能要件と理解すること Point 02 大規模システム＝ステークホルダーが多い中での、スムーズな構築・運用のためのコミュニケーション Point 03 持ちうる全てをフル活用した、技術的意思決定のための選択肢 Point 04
36. ©Fusic Co., Ltd. 35 OSEKKAI × TECHNOLOGY ココロと技術で、ぴったりも、びっくりも。 Thank You ご清聴いただきありがとうございました Let’s Talk! カジュアル面談もお気軽に！