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

Slide 1

Slide 1 text

©Fusic Co., Ltd. 0 大規模サーバーレスAPIの堅牢性・信頼性設計〜AWSのベストプラクティスから始まる現実的制約との向き合い方〜 2025.10.11 Mai Miyazaki @maimyyym JAWS FESTA 2025 in 金沢

Slide 2

Slide 2 text

©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!!

Slide 3

Slide 3 text

©Fusic Co., Ltd. 2 お話すること金沢だからこそ題材：多くのアクセスを捌くかつ予期しないスパイクがあるシステム一つのベストプラクティスだけが絶対解ではない JAWSをはじめ、多くの勉強会で広げた知見があったからやってこれたそんな経験をこの場で共有します

Slide 4

Slide 4 text

©Fusic Co., Ltd. 3 CONTENTS 目次 1. 題材となるシステムの紹介 2. 絡み合う制約 3. 包括的な信頼性設計へ 4. 解に至るまで

Slide 5

Slide 5 text

©Fusic Co., Ltd. 4 題材となるシステムの紹介システムアーキテクチャ / 求められていたこと 1

Slide 6

Slide 6 text

©Fusic Co., Ltd. 5 システムのアーキテクチャ紹介題材となるシステムの紹介 ▪ プライベートAPI Gateway → Lambda → OpenSearchがAPIの基本構成 ▪ OpenSearchにデータを格納する機構もサーバーレスで構築 ▪ サーバーレスだが、考える範囲は非常に多い

Slide 7

Slide 7 text

©Fusic Co., Ltd. 6 求められていたこと題材となるシステムの紹介セキュリティ要件 ▪ データの適切な保護 ▪ 基準はAWSのベストプラクティス • 検知の仕組みがすでにある性能要件 ▪ P90で200〜500ms以下 ▪ エラー率0.01%未満 ▪ イレギュラーなピーク時にも落ちないこと ▪ リクエストは数十〜数百RPS 変更できないスケジュール要件安定稼働のための運用・監視体制

Slide 8

Slide 8 text

©Fusic Co., Ltd. 7 絡み合う制約 2つのスタートから始まる技術検証・意思決定 2

Slide 9

Slide 9 text

©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

Slide 10

Slide 10 text

©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

Slide 11

Slide 11 text

©Fusic Co., Ltd. 10 OpenSearchをVPCに置く影響 OpenSearch private化の検討 Lambda関数のVPCアタッチ OpenSearchダッシュボード利用のための踏み台EC2構築

Slide 12

Slide 12 text

©Fusic Co., Ltd. 11 OpenSearchをVPCに置く影響 OpenSearch private化の検討 Lambda関数のVPCアタッチ OpenSearchダッシュボード利用のための踏み台EC2構築

Slide 13

Slide 13 text

©Fusic Co., Ltd. 12 Lambda VPCアタッチの影響 OpenSearch private化の検討気になるのは性能への影響 - コールドスタートは意外と大きな問題ではなかった - 2019年のアップデートで大幅に改善されていた - 実測したところ、差はあまりない(むしろ速い) 非VPC VPCアタッチ Init 3.42s Init 2.51s ※その他対策も重ね、今は100ms以下になっています

Slide 14

Slide 14 text

©Fusic Co., Ltd. 13 Lambda VPCアタッチの影響 OpenSearch private化の検討気になるのは性能への影響 - アプリケーションメトリクスの外部送信レイテンシ - 監視要件で避けられない - NAT Gatewayを配置する必要がある高トラフィック＝転送するメトリクス量は膨大＝コストへの影響 Lambda実行時間への懸念検証しないと見えない + 複数チームの連携が必須大規模プロジェクトだからこそ技術的意思決定のための検証コスト・スケジュール制約が発生

Slide 15

Slide 15 text

©Fusic Co., Ltd. 14 OpenSearchをVPCに置く影響 OpenSearch private化の検討 Lambda関数のVPCアタッチ OpenSearchダッシュボード利用のための踏み台EC2構築

Slide 16

Slide 16 text

©Fusic Co., Ltd. 15 VPC内OpenSearchダッシュボードアクセス OpenSearch private化の検討 [前提] VPC外のOpenSearchダッシュボードはパブリックにアクセス可能 ※認証 / IP制限の実装可

Slide 17

Slide 17 text

©Fusic Co., Ltd. 16 VPC内OpenSearchダッシュボードアクセス OpenSearch private化の検討 VPC内OpenSearchの場合、踏み台サーバーが必要に • 体感として通信速度が遅い • セッションが切れると再接続 • EC2の管理コスト・セキュリティ対策運用コストの増大検証してみた

Slide 18

Slide 18 text

©Fusic Co., Ltd. 17 OpenSearchをVPCに置くことは… OpenSearch private化の検討選ばなかった監視要件 NAT Gatewayを置く運用に必要なダッシュボードへのアクセスがEC2経由に Lambda実行時間の増加 → 性能面への懸念転送量が過多 → 料金コストの懸念 EC2の構築・運用コストセキュリティ面の考慮ポイント増加

Slide 19

Slide 19 text

©Fusic Co., Ltd. 18 OpenSearchをVPCに置くことは… OpenSearch private化の検討選ばなかった監視要件 NAT Gatewayを置く運用に必要なダッシュボードへのアクセスがEC2経由に Lambda実行時間の増加 → 性能面への懸念転送量が過多 → 料金コストの懸念 EC2の構築・運用コストセキュリティ面の考慮ポイント増加〜絡み合う制約〜残る課題は…セキュリティ

Slide 20

Slide 20 text

©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

Slide 21

Slide 21 text

©Fusic Co., Ltd. 20 Serverless化は… Amazon OpenSearch Serverlessへの移行検討目的スパイク対策

Slide 22

Slide 22 text

©Fusic Co., Ltd. 21 Serverless化は…選べなかった Amazon OpenSearch Serverlessへの移行検討 ◼ IP制限 ◼ 複数ベンダー・チームのユーザー管理期待するアクセス制御ができない ◼ 必須のプラグインを使えない ◼ 必須のAPIがサポートされていないそもそもシステム要件を満たせない目的スパイク対策

Slide 23

Slide 23 text

©Fusic Co., Ltd. 22 Serverless化は…選べなかった Amazon OpenSearch Serverlessへの移行検討 ◼ IP制限 ◼ 複数ベンダー・チームのユーザー管理期待するアクセス制御ができない ◼ 必須のプラグインを使えない ◼ 必須のAPIがサポートされていないそもそもシステム要件を満たせない残る課題は・・・スパイク対策

Slide 24

Slide 24 text

©Fusic Co., Ltd. 23 包括的な信頼性設計へ守りたかったベストプラクティスから、多層的なベストプラクティスの実装へ考慮レイヤーがシンプルになる効果 3

Slide 25

Slide 25 text

©Fusic Co., Ltd. 24 守りたかった、ベストプラクティス包括的な信頼性設計へ “AWSのベストプラクティス” クラウドを利用する上で、準拠したいなぜなら、これを守ることが安定運用につながるから。とくにセキュリティ標準のCriticalな事項に従わない選択は苦しい

Slide 26

Slide 26 text

©Fusic Co., Ltd. 25 多層的に実装するベストプラクティス包括的な信頼性設計へセキュリティ検知の運用において、「Supress(抑制)」という選択がある特定のアラートを無視するための選択肢個人的な見解として、「抑制できる」という意味を感じる

Slide 27

Slide 27 text

©Fusic Co., Ltd. 26 多層的に実装するベストプラクティス包括的な信頼性設計へ OpenSearchへのアクセスを絞る • リソースポリシーでLambda実行ロールのみ許可 • インデックス操作をOpenSearch内部でも絞る最小権限の徹底 • OpenSearch 監査ログの出力追跡可能性 • CloudWatchアラーム → 通知機構の構築 • CloudWatchダッシュボード構築 • 実測に基づくインスタンスタイプ等の値決定監視→スケーリング運用すごく時間がかかるものではない最初にやればいいだけ、後から楽できるものそんな、一つ一つはとても小さくて細かな設定作業を積み重ね、Criticalを抑制した

Slide 28

Slide 28 text

©Fusic Co., Ltd. 27 考慮レイヤーがシンプルになる効果包括的な信頼性設計へ実際にサービスインして・・・大規模トラフィックを捌くため、高負荷・高レイテンシ時の原因調査が多々発生どこがボトルネックか？をレイヤーごとに追跡していくため、 OpenSearchをVPCに置かないことで考慮レイヤーがよりシンプルにこの選択が正解だったと言える

Slide 29

Slide 29 text

Slide 30

Slide 30 text

©Fusic Co., Ltd. 29 考慮レイヤーがシンプルになる効果包括的な信頼性設計へ実際にサービスインして・・・サーバーレス・オートスケールだけに頼れない、人間による判断の必要性運用開始後のパフォーマンス改善のためのメトリクス追跡 CloudWatchダッシュボードが大活躍！・API Gateway: Count, 5xxError, Latency ・Lambda: Invocations, Throttles, Duration, ProvisionedConcurrentExecutions ・OpenSearch: CPUUtilization, JVMMemoryPressure, SearchLatency ※中身は隠してお届けします。実際はとってもおもしろい！手動スケールの判断材料に

Slide 31

Slide 31 text

Slide 32

Slide 32 text

©Fusic Co., Ltd. 31 大規模サーバーレスだからこそ解に至るまでサーバーレスだからこそ・・・ • サーバーの管理・運用がAWSマネージドだからこそ、限界への挑戦が起こりうる • AWSマネージドにできるからこそ、求められるさまざまな要件に対して向き合い、考えることにエネルギーを使える

Slide 33

Slide 33 text

©Fusic Co., Ltd. 32 何を考えていたか解に至るまで大規模システムでの技術的意思決定の勘所 • システムの意義は何か。そこから「何をやらず、その代わりにどうするか。」選択肢を積み上げていく。 • セキュリティ・性能があった上での安定稼働・運用。スケジュール・リソースの中で、焦らず構築していくこと。 • 見えない部分も含めた全体最適。何を求められているか、を汲み取るコミュニケーション。

Slide 34

Slide 34 text

©Fusic Co., Ltd. 33 何を考えていたか解に至るまで一つのベストプラクティスを守ることだけが絶対解ではない・・・という解に至るまで。幅広い知恵を掻き集めるように、フル回転した。社内の集合知の活用勉強会参加で脳内に作られた知識のインデックス ※絶対に守りましょうという話でも、守らなくてもいいという話でもない

Slide 35

Slide 35 text

©Fusic Co., Ltd. 34 学び得た、大切なこと大規模サーバーレスAPIの堅牢性・信頼性設計多層的なベストプラクティスを実装し、考慮レイヤーを減らしていくこと Point 01 システムの意義を考え、安定稼働・運用のためのセキュリティ要件・性能要件と理解すること Point 02 大規模システム＝ステークホルダーが多い中での、スムーズな構築・運用のためのコミュニケーション Point 03 持ちうる全てをフル活用した、技術的意思決定のための選択肢 Point 04