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

ステートフルアプリケーションのコンテナ化の歴史/The journey of stateful...

ステートフルアプリケーションのコンテナ化の歴史/The journey of stateful containers

2025 年 11 月 7 日に開催された「JAWS-UGコンテナ支部 x ストレージ支部コラボ会」での登壇資料です。

https://storage-jaws.connpass.com/event/371127/

Avatar for Kyosuke Ochimizu

Kyosuke Ochimizu

November 10, 2025
Tweet

More Decks by Kyosuke Ochimizu

Other Decks in Technology

Transcript

  1. © 2025, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. ステートフルアプリケーションの コンテナ化の歴史 〜ストレージとコンテナが仲良くなるまで〜 落⽔ 恭介 (Ochimizu Kyosuke) Containers Specialist Solutions Architect Amazon Web Services Japan G.K.
  2. © 2025, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. ⾃⼰紹介 2 落⽔ 恭介 (Ochimizu Kyosuke) コンテナスペシャリスト ソリューションアーキテクト Ø 教育業界ベンチャー Ø SIer Ø サポートチーム / アマゾン ウェブ サービス ジャパン Ø 現在のロール 好きな AWS サービス: AWS Fargate
  3. © 2025, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 3 質問︕ コンテナでステートフルなアプリケーションを動かしていますか︖ 🙋 🙅
  4. © 2025, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 4 ステートフルなコンテナアプリ運⽤は増加傾向 Cloud Native 2024︓コード、クラウド、そして変⾰の10年に迫る - The Linux Foundation https://www.linuxfoundation.jp/publications/2025/05/cncf-2024-annual-survey-jp/ “2024 年、組織の 74% がコンテナをステートフル アプリケーションの管理に利⽤していると報告し、 2023 年から 10% 増加しました(図 20)。” “しかし、この採⽤は頭打ちになりつつある可能性 があります︓ステートフルアプリケーションの管 理にコンテナの将来的な利⽤を計画または評価し ている企業の数は、2023 年から 44% 減少しまし た。”
  5. © 2025, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 5 ステートレス or ステートフル︖ • 「コンテナアプリはステートレスに設計する」という⽅針は 2025 年現在でもベストプラクティス Ø 参考: Design principles - Container Build Lens (AWS Well-Architected Framework) • コンテナのメリットは可搬性の⾼さ Ø コンテナの可搬性の⾼さ、および可搬性を前提としたコンテナオーケストレーターによる ⾃動化により、コンテナのメリットを享受できる Ø ステートレスアプリの⽅が、これらのメリットを享受しやすい 効率的な オペレーション スケーラビリティ リソースの有効活⽤
  6. © 2025, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 6 「ベストプラクティスに従わない = 悪」ではない • ステートフルアプリをコンテナで動かすことが妥当な状況はありうる Ø 例) 利⽤したいデータベース、キャッシュ、キューがマネージド型サービスで提供されていない Ø 例) CI/CD での統合試験の⽬的に、短命な使い捨ての環境として利⽤ • 技術の発展により、運⽤負荷の差異は少なくなってきている Ø 「ステートフルアプリによる運⽤負荷の増加」と「ステートフルアプリをなくすための労⼒」の 損益分岐点が下がりつつある ステートフル アプリの運⽤負荷 リアーキテクチャ の⼯数
  7. © 2025, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 7 質問︕ ステートフルコンテナの運⽤で⼀番困った課題は︖ 😅
  8. © 2025, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 8 なぜステートフルコンテナが難しいのか • コンテナアプリが状態を保存するためには、何らかの永続化層(ストレージ)が必要 Ø デフォルトでコンテナが利⽤可能なストレージは⼀時的であり、コンテナの停⽌時に削除される • コンテナのライフサイクル(起動 → 実⾏ → 停⽌)をまたいでストレージを使い続けるためには、 以下の点を達成できる必要がある Ø コンテナとはライフサイクルが独⽴しているストレージの⽤意 Ø コンテナの起動に合わせたストレージへのアクセス⼿段の提供 Ø コンテナのライフサイクルを超えたアプリケーションとストレージの識別 • (コンテナに限らず)ステートフルアプリの運⽤は⼤変 Ø 可⽤性、バックアップ、スケーラビリティ、セキュリティパッチ適⽤
  9. © 2025, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 9 コンテナとストレージの歴史 (1) コンテナホストでストレージを利⽤可能にしておき、後から起動するコンテナからアクセスさせる Ø コンテナオーケストレーター側での機能拡張に伴い、この⽅法は徐々に不要となっていった Ø 現在でもコンテナオーケストレーターが⾮対応な機能であれば、この⽅法が必要なケースも コンテナホスト 1. コンテナホストの起動時に ボリュームをアタッチ / マウント コンテナホスト 2. コンテナの起動時に 当該ディレクトリをバインドマウント $ mkdir /my-storage $ mount <options> /my-storage --mount type=bind,\ source=/my-storage,\ target=/app
  10. © 2025, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 10 コンテナとストレージの歴史 (1) • この⽅法によりコンテナのライフサイクルをまたいでストレージが利⽤可能になった • ただし、運⽤負荷という観点で課題が残る⽅法となっていた Ø 可搬性の低下 Ø スケジューリングの複雑化 コンテナ起動 コンテナ停⽌ コンテナ起動 コンテナホスト
  11. © 2025, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 11 コンテナとストレージの歴史 (2) コンテナオーケストレーター側で、コンテナと連動したストレージ管理機能が充実していく • Amazon Elastic Container Service (ECS) Ø Amazon Elastic File System (EFS) / Amazon Elastic Block Store (EBS) のネイティブサポート • Kubernetes Ø Persistent Volume (PV) / Persistent Volume Claim (PVC) / Storage Class が GA Ø StatefulSet が GA 1. ストレージを利⽤するための ECS タスク定義や Kubernetes マニフェストを作成 2. コンテナの起動時にストレージが利⽤可能となるように コンテナ(コンテナホスト)をセットアップ コンテナホスト
  12. © 2025, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 12 [補⾜] ECS における EBS ボリュームのアタッチ • 現時点で、ECS のネイティブな統合で EBS ボリュームをアタッチする場合、以下の制約が存在 Ø 新規ボリュームのみアタッチ可能(空のボリューム or スナップショット) Ø ECS サービスのタスクは、タスク終了時にアタッチした EBS ボリュームが削除される • 上記の制約から、ECS サービスを利⽤場合、タスクのライフサイクルを超えて同⼀の EBS ボリュームを利⽤できない Ø すなわち、 ECS ネイティブな EBS 統合で起動する ECS タスクにて、 EBS ボリュームを利⽤するステートフルなアプリケーションを実⾏することは現状難しい • (現時点での)想定ユースケースは、⼤規模データに対する ETL のような、 ⾼い I/O パフォーマンスや既存のデータセットの参照を必要とするワークロード
  13. © 2025, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 13 コンテナとストレージの歴史 (3) コンテナから利⽤可能なストレージオプションが拡充されていく Ø Mountpoint for Amazon S3 が⼀般提供を開始 Ø ECS や EKS のコンテナから、ファイルシステムを経由して Amazon Simple Storage Service (S3) の オブジェクトにアクセス可能に コンテナホスト S3 Bucket Mountpoint for S3 read (2) GetObject API
  14. © 2025, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 14 コンテナとストレージの未来 例: Container Object Storage Interface (COSI) Ø オブジェクトストレージのバケットをプロビジョニング & アクセス管理するための標準規格 Ø CSI と似た概念 例: ORAS (OCI Registry As Storage) Ø OCI レジストリをコンテナイメージだけでなく汎⽤ストレージとして活⽤するためのプロジェクト Ø Gitless GitOps のような⽐較的新しい概念との親和性も⾼い Introduction - Container Object Storage Interface https://container-object-storage-interface.sigs.k8s.io/ OCI Registry As Storage https://oras.land/
  15. © 2025, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 15 まとめ • コンテナで「ステートフルアプリケーション」を動かすことは、現代においては 普通の選択肢といえる • ステートレスアプリケーション」として設計することがベストプラクティスとなる 点は変わらない Ø ただし、運⽤負荷の⼤きさやオーケストレーターの制約といった差異は 技術の発展により⼩さくなりつつある 「すべてがコンテナになる」⽇は近い ... かもしれない︕
  16. © 2025, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. Thank you! © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved.