Elastics Cloud Serverless：ステートフルからサーバーレスへの技術的移行

Elasticは、データを素早く検索・分析するための強力な基盤として長年活用されてきました。しかし、クラウドネイティブな環境が標準となるにつれ、従来のデータ管理手法である「ステートフル」モデルでは対応しきれない課題も顕在化しています。

これまでのElasticは、データ処理を行う「コンピューティング」と、データを保存する「ストレージ」が一体となった構成でした。この方式は確かな実績を持つ一方で、システムの拡張や管理運用において、手間やコストが増大しやすいという側面がありました。

そこで新たに登場したのが、「サーバーレス」アーキテクチャです。本稿では、これら二つの方式を比較しながら、サーバーレスアーキテクチャが実現する「コンピューティングとストレージの分離」が、いかにして高い運用効率、柔軟な拡張性、そして優れたコスト効率をもたらすのかを解説します。

従来のステートフルアーキテクチャのレビュー
1. 基本構成とデータ階層化
2. 運用上の課題
サーバーレスアーキテクチャの登場
詳細なプロセス比較：インデックス作成と検索
運用の変革：自動スケーリングとコスト効率
1. 負荷に応じた自動スケーリング
2. コストモデルの最適化
現状の考慮事項と制限
サービス提供開始時期と日本での利用について
Elastic Cloud Serverless についてのよくある質問
結論
1. 参考：用語の意味
2. 参考：リンク集

従来のステートフルアーキテクチャのレビュー

サーバーレスモデルがもたらす革新性を正確に評価するためには、まずその前身である従来のステートフルアーキテクチャの構造と、それが直面していた運用上の課題を理解することが重要です。

基本構成とデータ階層化

ステートフルアーキテクチャにおけるデータ管理は、一般的にインデックスライフサイクル管理（ILM）に基づいた階層化が特徴です。

Hot層: 最もアクティブなデータが配置される階層です。インデックス作成（書き込み）と検索クエリが集中するため、高性能なローカルSSDが使用されます。ここでは可用性と耐障害性を確保するため、プライマリとレプリカの両方のシャードが保持されます。
Warm/Cold層: アクセス頻度が低下したデータが移動する階層であり、コスト効率の良いストレージが利用される傾向にあります。
Frozen層: ほとんどアクセスされないアーカイブデータを格納する階層です。S3などのオブジェクトストレージ上のスナップショットをソースとし、必要なデータのみをキャッシュにマウントすることで、ストレージコストの大幅な削減を図ります。

運用上の課題

この階層化モデルは有効に機能してきましたが、運用上、いくつかの課題も指摘されていました。

コンピューティングとストレージの密結合: 大きな課題の一つは、CPUやRAMとローカルディスクが不可分である点です。ストレージ容量のみを増強したい場合でもコンピューティングリソースを同時にスケールアップする必要があり、結果として「オーバープロビジョニング」による不要なコストが発生するケースが見られました。
シャード再配置のコスト: ノードの追加・削除や障害時には、クラスター全体でシャードの物理的なデータコピー（再配置）が発生します。これには帯域消費と時間を要するため、頻繁なアップグレードやスケーリングが躊躇され、結果としてCVEへの対応遅延など俊敏性に影響を与える要因となっていました。
管理の複雑さ: 利用者は、自身のワークロードに合わせてクラスターのサイジングを決定し、適切なILMポリシーを設計・設定する必要があります。どのデータをどのタイミングでHot層からWarm層へ移動させるかといった判断は、利用者の専門知識と経験に依存し、運用管理の負担となる場合がありました。

サーバーレスアーキテクチャの登場

これらの課題への回答の一つとして登場したのが、サーバーレスアーキテクチャです。

中核概念：コンピューティングとストレージの分離

最大の変化は、データ（セグメントファイル）がノードのローカルディスクではなく、S3のようなオブジェクトストレージにプライマリストアとして一元保存される点にあります。これにより、ノードはデータの永続保持責任から解放され、実質的に「ステートレス」となります。インデックス作成（書き込み）専用ノードと、検索（読み取り）専用ノードに分離され、それぞれ独立して管理・スケーリングすることが可能になりました。

「スィンシャード（Thin Shards）」による効率化

このアーキテクチャを支える技術が「ツィンシャード」です。従来のシャードとは異なり、初期状態ではメタデータのみを保持します。データの実体はオブジェクトストレージから必要に応じて読み込まれるため、ノードは軽量な状態を維持できます。これは大規模クラスターにおけるリソース効率の向上に寄与すると考えられます。

シャード再配置問題の解決

この分離により、ノード追加時にはオブジェクトストレージからメタデータを読み込むだけで済むため、ノードの起動が非常に高速化されました。大規模なデータ転送が発生しにくいため、ローリングアップグレードやスケーリングがネットワーク帯域を圧迫することなく実行可能となります。

詳細なプロセス比較：インデックス作成と検索

データライフサイクルにおける具体的なプロセスも変革されています。

ステートフルモデルのデータフロー

従来は、インメモリバッファへの格納と同時にローカルディスクのトランザクションログへ書き込み、その後refresh操作で検索可能にし、flush操作でディスクへ永続化するというフローが一般的でした。

サーバーレスモデルのデータフロー

インデックス作成ノード: ドキュメント受信後、トランザクションログがオブジェクトストレージにアップロードされ、その完了確認をもってクライアントにACKが返されます。これにより、単一ノードのディスクに依存するよりも高い耐久性が期待できます。
検索ノード: クエリに必要なセグメントファイルのみをオブジェクトストレージからオンデマンドで取得します。また、インデックス直後の最新データに対しては、検索ノードがインデックス作成ノードに直接問い合わせを行うことで、リアルタイムに近い検索体験を提供するよう設計されています。

出典）https://www.elastic.co/jp/cloud/serverless

最適化：バッチコミット

オブジェクトストレージへのAPIコール回数を最適化するため、「バッチコミット」という技術が採用されています。複数のコミットを論理的にグループ化し、差分データのみを追加することで、コストとパフォーマンスの両立を図っています。

運用の変革：自動スケーリングとコスト効率

このアーキテクチャは、運用の自動化とコスト最適化にも直結します。

負荷に応じた自動スケーリング

インジェスト量や検索クエリ量に基づき、インデックス作成ノードと検索ノードがそれぞれ独立して自動的にスケールします。なお、コールドスタート（スケールアップ時の初期レイテンシ）を回避したい場合は、「サーチパワー（search power）」設定により、アイドル時でも最低限のノードを維持する運用が可能です。

コストモデルの最適化

ストレージとコンピューティングの分離、自動スケーリングによるオーバープロビジョニングの解消、そして従量課金モデルの組み合わせにより、TCO（総所有コスト）の削減が期待できる構造となっています。

現状の考慮事項と制限

サーバーレスアーキテクチャは強力ですが、採用にあたっては現時点での実装における制約を理解しておく必要があります。

リフレッシュレートの調整: オブジェクトストレージへの負荷軽減のため、リフレッシュレートにはスロットリング（制限）が設けられています（例：15秒に1回など）。
シャード数設定: ユーザーによる手動設定は提供されず、プラットフォームによる自動管理となります。

サービス提供開始時期と日本での利用について

本サービスは2024年12月に一般提供（GA）が開始されました。そして、日本のユーザーにとって待望のAWS 東京リージョン（ap-northeast-1）での提供は、2025年10月より開始されています。

Elastic Cloud Serverlessは、開発者がインフラ管理よりもデータの価値創出に集中できる環境を提供します。現在は14日間の無料トライアルも提供されているため、興味のある方はぜひ実際にその挙動を試し、次世代のパフォーマンスを体感してみてください。

日本国内での導入支援体制についてご案内します：
サイオステクノロジーは、Elasticの国内初のディストリビューターです。現在、Elastics社と共同で、Elasticがグローバルに提供している「サーチ」「セキュリティ」「オブザーバビリティ」の3つのソリューションについて、日本国内における展開を強化しております。
サーバーレスアーキテクチャへの移行や、具体的な導入・活用方法についてご不明な点がございましたら、どうぞご遠慮なく弊社までお問い合わせください。

Elastic Cloud Serverless についてのよくある質問

以下は、2025年11月時点の公式ドキュメント（Elastic Docs）に基づくFAQの抜粋です。

料金と提供地域

Q：Serverless の料金についてはどこで確認できますか？
- A：Elasticsearch Serverless、Observability Serverless、および Elastic Security Serverless の各料金情報ページをご覧ください。
Q：Elastic Cloud Serverless はどのクラウドリージョンでサポートされていますか？
- A：選定されたAWS／GCP／Azureのリージョンで利用可能です。今後、対応リージョンの拡大も計画されています。詳細は公式ドキュメントの「Regions」をご参照ください。

データ管理

Q：Serverless プロジェクトへ、またプロジェクトからデータを移動するにはどうすればいいですか？
- A：現在、データ移行ツールを開発中です。暫定的には、Logstashを使用し、Elasticsearch入出力プラグインを通じてServerlessプロジェクトとのデータ移動を実施してください。
Q：Serverless プロジェクトに対してバックアップやリストアのリクエストはできますか？
- A：プロジェクトのバックアップやリストア要求は、現時点ではサポートされていません。データ移行ツールの強化が進められています。

セキュリティ、準拠、アクセス

Q：Elastic Cloud Serverless のサービスアカウントはどう作成できますか？
- A：Serverlessプロジェクト内でサービスアカウントのAPIキーを作成してください。将来的にはTerraform等のツールによるAPIキー作成の自動化オプションも提供される予定です。
Q：Elastic Cloud Serverless はどのようなコンプライアンスおよびプライバシー基準に準拠していますか？
- A：Elasticプラットフォーム全体と同様に、独立監査を受け、主要なコンプライアンスおよびプライバシー基準を満たすよう認証されています。詳しくはElastic Trust Centerをご覧ください。特定の基準に関してはロードマップに記載があります。

プロジェクトのライフサイクルとサポート

Q：Elastic Cloud Serverless はソフトウェアのバージョン互換性をどのように確保していますか？
- A：アップグレード時にも接続や設定には影響が出ないよう設計されています。互換性維持のため、品質テストおよびAPIバージョニングが用いられています。
Q：Serverless プロジェクトを Hosted 型（Elastic Cloud Hosted）への変換、あるいは Hosted 型を Serverless プロジェクトに変換できますか？
- A：プロジェクトおよびデプロイメントは異なるアーキテクチャに基づいているため、相互の変換はできません。
Q：Serverless プロジェクトを別のタイプのプロジェクトに変換できますか？
- A：プロジェクトを別タイプに変換することはできませんが、必要に応じて任意の数のプロジェクトを作成可能です。課金は実際の使用量に基づきます。
Q：Elastic Cloud Serverless のサポートケースを提出するにはどうすればいいですか？
- A：普段お使いのサブスクリプションに対してケースを作成してください。ケース本文に「Serverless プロジェクトを使用中」である旨を記載すると、適切なサポートが受けられます。

結論

Elasticのサーバーレスアーキテクチャへの移行は、コンピューティングとストレージの分離、オブジェクトストレージの活用、そしてスィンシャードという技術革新によって実現されました。これにより、スケーラビリティの向上や運用管理の簡素化、コスト効率の改善が見込まれます。

参考：用語の意味

インデックスライフサイクル管理 (ILM): データを作成から削除までポリシーに基づいて自動管理する機能。
オーバープロビジョニング: ピーク時の負荷や将来の増加を見越して、必要以上のリソース（CPU、メモリ、ストレージ）をあらかじめ確保しておくこと。
トランザクションログ (Translog): データの変更操作を記録するログ。メモリ上のデータがディスクに永続化される前にクラッシュした場合のデータ復旧に使用されます。
セグメントファイル: Elasticsearch（内部のLucene）におけるインデックスの構成単位。不変（Immutable）なファイルとして保存されます。
ローリングアップグレード: サービスを停止させることなく、クラスター内のノードを1台ずつ（または一部ずつ）順番に更新していく手法。
コールドスタート: サーバーレス環境において、リクエストが発生してからリソースが立ち上がり、処理が可能になるまでに生じる初期遅延のこと。
CVE (Common Vulnerabilities and Exposures): 共通脆弱性識別子。公開されているセキュリティ脆弱性に対して割り当てられる固有のID。
総所有コスト (TCO): システムの導入から運用、維持管理にかかる費用の総額。
ACK (確認応答): 一般的なネットワーク用語です。