この記事は Introducing advanced Kubernetes control plane configuration in Amazon EKS (記事公開日: 2026 年 8 月 12 日) を翻訳したものです。 大規模な Amazon Elastic Kubernetes Service (Amazon EKS) クラスターを運用するお客様は、リソースの使用率を高めてコンピューティングコストを下げるために、Pod の配置戦略を最適化したいと考えています。入れ替わりの激しいバッチ、継続的インテグレーションと継続的デリバリー (CI/CD)、AI と機械学習 (AI/ML) のワークロードを実行するチームは、etcd のストレージの逼迫を抑えるために、イベントの保持期間などのリソースのライフサイクル管理の設定をカスタマイズしたいと考えています。また、セルフマネージドの Kubernetes から移行するお客様は、長年調整してきたスケジューラの設定を引き継ぎたいと考えています。これまで、こうしたニーズの多くに応えるには独自の仕組みを構築して維持する必要があり、運用オーバーヘッドとメンテナンスの負担が増えていました。2026 年 8 月に、Amazon EKS は高度な Kubernetes コントロールプレーン設定の提供を開始しました。API サーバー、スケジューラ、コントローラーマネージャーのパラメータを、Amazon EKS で直接設定できるようになりました。Amazon EKS の可用性とパフォーマンス特性は、これまでと変わりません。 この記事では、この機能の概要とサポートされているパラメータを説明したうえで、2 つのウォークスルーで実際に試します。まず、 MostAllocated スコアリング戦略を使って、デフォルトの分散配置よりもリソースの使用率を優先するように Pod の配置戦略を設定します。次に、デバッグのしやすさとストレージの効率のバランスを取るように、イベントの保持期間を設定します。 設定できる項目 スケジューラのカスタマイズでは、Pod の配置戦略を設定して、Pod のスケジューリングでノードをどのようにスコアリングするかを制御できます。デフォルトでは、Kubernetes スケジューラは LeastAllocated スコアリング戦略を使います。この戦略は、可用性を重視して、リソースの割り当てが少ないノードを優先します。 MostAllocated スコアリング戦略は、すでに割り当てが多いノードを優先し、リソースの使用率を最適化します。 MostAllocated 戦略では、使用率がすでに高いノードに Pod を詰め込むので、同じワークロードをより少ないノードで実行できます。その結果、コンピューティングコストが下がり、クラスター内で一部しか使われていないインスタンスが減ります。 コントローラーマネージャーの設定では、 Horizontal Pod Autoscaler (HPA) がスケーリングを判断する頻度を制御できます。同期間隔を短くすると、HPA コントローラーがメトリクスを評価して対応する頻度が上がるので、負荷が増えてからワークロードがスケールアウトするまでの時間が短くなります。 Amazon EKS Provisioned Control Plane のクラスターでは、最近の改善で HPA の同期の同時実行数が Kubernetes のデフォルト値の最大 40 倍に引き上げられていて ( 発表 )、同期間隔の設定と組み合わせて使えます。同時実行数の引き上げと同期間隔の短縮によって、HPA コントローラーはより多くのスケーリングイベントを並列に処理し、ワークロードの需要の変化にすばやく対応できます。その結果、Pod のオートスケーリングが速くなり、需要の変化への応答性が高まります。 API サーバーでは、 イベントの保持期間 を設定して、デバッグのしやすさとストレージの効率のバランスを取れます。バッチパイプライン、CI/CD ランナー、AI/ML ジョブなど、Pod の入れ替わりが激しいクラスターでは、大量の Kubernetes イベントが生成されます。これらのイベントは etcd の領域を消費し、クラスターの動作に必要なオブジェクトと領域を奪い合います。保持期間を短くすると、こうした短期間しか使わない診断データが早く消去されるので、etcd のデータ量を抑え、list と watch のリクエストを速くできます。一方、保持期間を長くすると、チームがトラブルシューティングに使える履歴が増えます。また、 NodePort タイプの Service に割り当てるポート番号の範囲 を変更して、ポートの割り当てを組織のネットワークとファイアウォールのポリシーに合わせたり、NodePort タイプの Service を多数実行するクラスターで範囲をデフォルトより広げたりすることもできます。この設定は移行の際に役立ちます。レガシーアプリケーションとその呼び出し元のクライアントは、特定の固定ポートでサービスが提供されることを前提にしていることがよくあります。それらのポートが Kubernetes のデフォルトの範囲外にある場合、通常はアプリケーションを変更するか、アプリケーションの前に外部のプロキシを立てる必要があります。範囲をアプリケーションがすでに使っているポートに合わせれば、その作業が不要になり、アプリケーションを書き直したり、保守が必要なネットワークコンポーネントを追加したりせずに、ワークロードを Amazon EKS に移行できます。 提供開始時にサポートされるパラメータ 次の表に、提供開始時に使用できるパラメータをまとめます。サポートされている値と範囲を含む全一覧は、 Amazon EKS のドキュメント をご覧ください。 コンポーネント パラメータ 制御する内容 kube-scheduler nodeResourcesFit.scoringStrategy リソースの割り当てに基づいてノードをスコアリングし、Pod の配置戦略を設定します。MostAllocated はすでに割り当てが多いノードを、LeastAllocated は使用可能なリソースが多いノードを優先します。cpu、memory、アクセラレーター (nvidia.com/gpu、aws.amazon.com/neuron、aws.amazon.com/neuroncore) に、リソースごとの重み (1～100) を指定できます。 kube-controller-manager horizontalPodAutoscalerControllerConfig.horizontalPodAutoscalerSyncPeriod アプリケーションの要件に合わせて、HPA がメトリクスを評価してスケーリングを判断する頻度 (10～15 秒) を設定します。 kube-apiserver eventTtl デバッグのしやすさと etcd のストレージの効率のバランスを取るように、イベントの保持期間 (10～60 分) をカスタマイズします。 kube-apiserver serviceNodePortRange NodePort タイプの Service に割り当てるポート番号の範囲 (10260～32767) を定義します。アプリケーションを変更せずにレガシーシステムを移行できます。 注: horizontalPodAutoscalerSyncPeriod パラメータを使うには、 Amazon EKS Provisioned Control Plane が必要です。Provisioned Control Plane は、負荷の高いワークロードに常に対応できるコントロールプレーンのキャパシティを事前に割り当て、追加の負荷を吸収できるサイズを確保します。 これらはクラスター全体の設定で、クラスターで実行されるワークロードに適用されます。前の表は、お客様の要望に基づいて選んだ、最初にサポートするパラメータの一覧です。他に設定したいパラメータがあれば、 AWS Containers Roadmap でお知らせください。 前提条件 このウォークスルーを実施するには、次のものが必要です。 AWS アカウント Kubernetes バージョン 1.31 以降を実行している Amazon EKS Auto Mode クラスター 手元のデバイスで設定済みの最新バージョンの AWS コマンドラインインターフェイス (AWS CLI) 、または AWS CloudShell クラスターと通信できるように設定した kubectl Amazon EKS クラスターの情報の取得と更新、クラスターへのワークロードのデプロイを行うアクセス許可を持つ AWS Identity and Access Management (IAM) プリンシパル まず、クラスター名と AWS リージョンを設定します。 export CLUSTER=my-eks-cluster export AWS_REGION=us-west-2 ウォークスルー 1: MostAllocated スコアリング戦略による Pod の配置の最適化 このウォークスルーでは、既存のクラスターで MostAllocated スコアリング戦略を設定し、Kubernetes スケジューラが新しい Pod を、使用可能なリソースが多いノードではなく、すでに割り当てが多いノードに配置する様子を確認します。高度な Kubernetes コントロールプレーン設定を使えば、この戦略を Amazon EKS クラスターで直接設定できるので、カスタムスケジューラを維持する運用の負担がなくなります。 ステップ 1. ノードの使用率に偏りのあるクラスターを用意する この例では、Pod の数に関係なく一定数のノードを維持するために、 静的キャパシティのノードプール を設定した Amazon EKS Auto Mode クラスターを使います。静的キャパシティのノードプールは、予測可能なキャパシティやリザーブドインスタンスが必要なワークロードや、インフラストラクチャの規模を一定に保つことが求められるコンプライアンス要件のあるワークロードに役立ちます。ノードプールを作成します。 cat <<EOF | kubectl apply -f - apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: demo-static spec: replicas: 2 template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "node.kubernetes.io/instance-type" operator: In values: ["m5.large"] limits: nodes: 2 EOF kubectl wait --for=condition=Ready nodes --all --timeout=180s 両方のノードの準備ができたら、サイズの異なるワークロードをデプロイして、割り当てに偏りを作ります。 # 1 つのノードで重いワークロードを実行する (ノードのキャパシティの大半を使う) cat <<EOF | kubectl apply -f - apiVersion: apps/v1 kind: Deployment metadata: name: heavy-app spec: replicas: 1 selector: matchLabels: app: heavy-app template: metadata: labels: app: heavy-app spec: nodeSelector: karpenter.sh/nodepool: demo-static containers: - name: pause image: registry.k8s.io/pause:3.9 resources: requests: cpu: 1500m memory: 1Gi --- apiVersion: apps/v1 kind: Deployment metadata: name: light-app spec: replicas: 1 selector: matchLabels: app: light-app template: metadata: labels: app: light-app spec: nodeSelector: karpenter.sh/nodepool: demo-static containers: - name: pause image: registry.k8s.io/pause:3.9 resources: requests: cpu: 500m memory: 512Mi EOF kubectl wait --for=condition=Ready pods --all --timeout=120s 次のコマンドで、各ノードのリソースの割り当てを確認します。スケジューラは、スコアリングの判断に (実際の使用量ではなく) リソースの要求量を使います。 kubectl get pods -o wide kubectl describe nodes -l karpenter.sh/nodepool=demo-static | grep -A 5 "Allocated resources" Node: i-0b3a5fb6f3823fd2f Allocated resources: CPU Requests: 1500m (84%) Memory Requests: 1Gi (14%) Node: i-08c2daa17b2fbe865 Allocated resources: CPU Requests: 500m (28%) Memory Requests: 512Mi (7%) ノード A (i-0b3a5fb6f3823fd2f) は CPU の 84% が割り当てられています。ノード B (i-08c2daa17b2fbe865) は 28% だけです。kube-scheduler は、ノードをスコアリングするときに、この割り当ての差を使います。 ステップ 2. デフォルトの配置 (LeastAllocated) を確認する 新しい Pod をデプロイして、スケジューラがどのノードに配置するかを確認します。 cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: test-pod spec: nodeSelector: karpenter.sh/nodepool: demo-static containers: - name: pause image: registry.k8s.io/pause:3.9 resources: requests: cpu: 200m memory: 128Mi EOF kubectl wait --for=condition=Ready pods --all --timeout=120s kubectl get pods -o wide NAME READY STATUS NODE test-pod 1/1 Running i-08c2daa17b2fbe865 LeastAllocated では、スケジューラは使用可能なリソースが多いノードを優先し、Pod をノード B (CPU 28%、メモリ 7% が割り当て済み) に配置しました。先に進む前に、このテスト用の Pod を削除します。 kubectl delete pod test-pod ステップ 3. MostAllocated スコアリング戦略を有効にする 既存のクラスターにスケジューラの設定を適用します。 aws eks update-cluster-config \ --name "$CLUSTER" \ --kube-scheduler-config '{ "nodeResourcesFit": { "scoringStrategy": { "type": "MostAllocated" } } }' 注: 必要に応じて、カスタムの重みを指定した resources 配列を指定し、スコアリングの判断でどのリソースを重視するかを調整できます。サポートされているリソースは cpu 、 memory 、 nvidia.com/gpu 、 aws.amazon.com/neuron 、 aws.amazon.com/neuroncore で、重みは 1～100 です。 レスポンスとして、進行状況を追跡できる更新の情報が返されます。 { "update": { "id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "status": "InProgress", "type": "ControlPlaneComponentConfigUpdate" ... } Amazon EKS は、他のクラスターの更新と同様に、コントロールプレーンの設定の更新を非同期に適用します。更新が完了するまで待ちます。 aws eks wait cluster-active --name "$CLUSTER" このコマンドは、クラスターが Active ステータスに戻るまで待機します。通常は数分以内に戻ります。 ステップ 4. 新しい配置 (MostAllocated) を確認する これで、新しいスケジューリングの判断には MostAllocated が使われます。別のテスト用の Pod をデプロイして、どのノードに配置されるかを確認します。 cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: test-pod spec: nodeSelector: karpenter.sh/nodepool: demo-static containers: - name: pause image: registry.k8s.io/pause:3.9 resources: requests: cpu: 200m memory: 128Mi EOF kubectl wait --for=condition=Ready pods --all --timeout=120s kubectl get pods -o wide NAME READY STATUS NODE test-pod 1/1 Running i-0b3a5fb6f3823fd2f MostAllocated では、スケジューラは、すでにリソースの割り当てが多いノード A (CPU 84%、メモリ 14% が割り当て済み) を優先するようになりました。ノードアフィニティ、Taint と Toleration、トポロジー分散制約など、独自のスケジューリング要件を指定した Pod では、引き続きその要件が優先され、スケジューラはそれに従います。この詰め込む動作によって、時間がたつにつれて、使用率の低いノードには新しいワークロードが配置されなくなり、統合 (consolidation) に対応したノードプールでは、それらのノードを統合できるようになります。ポイントは、カスタムスケジューラを使わずに、1 回の API コールでクラスター全体のスケジューリング戦略を変更できたことです。 ウォークスルー 2: eventTtl によるイベントの保持期間の設定 Kubernetes は、Pod のスケジューリングの判断、イメージのプル、ヘルスチェックの失敗、スケーリングのアクションなどのクラスターのアクティビティを記録するために、イベントを etcd データベースに保存します。アップストリームのデフォルトでは、イベントは 1 時間保持されます。大規模なバッチジョブ、機械学習 (ML) のトレーニング、CI/CD パイプライン、大規模な CronJob など、入れ替わりの激しいワークロードを実行するクラスターでは、数千のイベントがすぐに蓄積します。etcd 内のイベントが増えると、ストレージが逼迫し、API サーバーの list 処理が遅くなるおそれがあります。 高度な Kubernetes コントロールプレーン設定では、デバッグのしやすさとストレージの効率のバランスを取るように、イベントの保持期間を調整できます。このウォークスルーでは、 eventTtl をデフォルトの 1 時間から 15 分に短縮します。 ステップ 1. eventTtl を 15 分に短縮する API サーバーの設定を適用します。 aws eks update-cluster-config \ --name "$CLUSTER" \ --kube-api-server-config '{ "eventTtl": "15m" }' 更新が完了するまで待ちます。 aws eks wait cluster-active --name "$CLUSTER" ステップ 2. 短縮の効果を確認する 新しい eventTtl の設定は、設定の変更が反映された後に Kubernetes が作成するイベントに適用されます。既存のイベントは元の保持期間を維持し、その期間に従って期限切れになります。保持期間が短くなったことを確かめるために、新しい Pod を作成して、その Pod のイベントを確認します。 kubectl run ttl-test --image=registry.k8s.io/pause:3.9 kubectl get events --field-selector involvedObject.name=ttl-test LAST SEEN TYPE REASON OBJECT MESSAGE 6s Normal Scheduled pod/ttl-test Successfully assigned default/ttl-test to i-0b3a5fb6f3823fd2f 3s Normal Pulled pod/ttl-test Container image "registry.k8s.io/pause:3.9" already present on machine 3s Normal Created pod/ttl-test Container created 3s Normal Started pod/ttl-test Container started 約 15 分後に、同じイベントを照会します。 kubectl get events --field-selector involvedObject.name=ttl-test No resources found in default namespace. Kubernetes が 15 分後にイベントをガベージコレクションで削除したことから、新しい保持期間が有効になっていることを確認できます。設定の変更前からあったイベントは、引き続き元の保持期間で期限切れになります。1 時間に数千のバッチジョブを実行するクラスターでは、この設定によって etcd の領域を大幅に空けられ、イベントを多く扱うクエリに対する API サーバーの応答時間を短縮できます。 イベントの保持期間を設定するタイミング 次のような場合は、 eventTtl を短くするのが適しています。 クラスターで、大量のイベントを生成するバッチ、CI/CD、ML のトレーニング、CronJob のワークロードを実行している。 etcd のストレージが容量の上限に近づいている。 イベントを永続的に保存するために外部のオブザーバビリティシステム ( Amazon CloudWatch Container Insights やログアグリゲーターなど) を利用していて、過去のイベントを調べるのに kubectl get events に頼っていない。 TTL を短くすると、 kubectl describe pod と kubectl get events で表示される期間も短くなることに注意してください。ストレージの効率とデバッグの手順のバランスが取れる値を選んでください。 クリーンアップ 継続的な料金が発生しないように、AWS アカウントで作成した Amazon EKS クラスターのリソースを必ず削除してください。 kubectl delete deployment heavy-app light-app kubectl delete pod test-pod kubectl delete nodepool demo-static Amazon EKS クラスターを削除するには、Amazon EKS のドキュメントの 手順 に従ってください。 考慮事項 高度な Kubernetes コントロールプレーン設定を適用する前に、次の点に留意してください。 既存の Amazon EKS API で管理: 高度な Kubernetes コントロールプレーン設定では、既存の CreateCluster API と UpdateClusterConfig API を新しいパラメータとともに使います。設定は、 AWS マネジメントコンソール 、AWS CLI、 AWS CloudFormation で適用できます。 eksctl 、AWS Controllers for Kubernetes (ACK)、Terraform のサポートも予定されています。(訳注: eksctl は、2026 年 8 月 14 日にリリースされた v0.230.0 でサポートされました。)Amazon EKS は各設定を適用する前に検証し、監査できるように変更を AWS CloudTrail に記録します。 設定はクラスター全体に適用: サポートされている各パラメータは、クラスター全体と、クラスターで実行されるワークロードに適用されます。Kubernetes がすでに従っている Pod レベルの指定 (Pod 自身のリソースの要求量など) は、引き続き適用されます。クラスターの設定で変わるのはコントロールプレーンのデフォルトとスコアリングの動作で、現在利用している Kubernetes の優先順位のルールは変わりません。 スケジューラとノード管理は別のレイヤーで動作: MostAllocated スコアリング戦略が影響するのは、スケジューラが、条件を満たす既存のノードのどれに Pod を配置するかです。Amazon EKS Auto Mode や Karpenter がノードをプロビジョニングしたり削除したりする方法は変わりません。設定を更新する前に、ワークロードでスケジューラとノード管理を組み合わせた動作を検証することをお勧めします。 一部のパラメータには Provisioned Control Plane が必要: horizontalPodAutoscalerSyncPeriod など、コントロールプレーンのパフォーマンスやリソースの消費に影響しうるパラメータは、 Provisioned Control Plane の階層を使うクラスターでのみ使用できます。 HPA の同期間隔とクラスターの規模: Provisioned Control Plane のクラスターでは、Amazon EKS は HPA の同期の同時実行数を Kubernetes のデフォルト値の最大 40 倍に引き上げています。同時実行数の引き上げと、HPA の同期間隔 (10～15 秒) を設定できることによって、HPA コントローラーはより多くのスケーリングイベントを並列に処理し、ワークロードの需要の変化にすばやく対応できます。HPA オブジェクトが多いクラスターでは、本番環境に適用する前に、選んだ同期間隔と HPA オブジェクトの数で期待どおりに動作するかを、お客様の環境で検証してください。 Kubernetes バージョンとリージョンのサポート: 高度な Kubernetes コントロールプレーン設定は、Kubernetes 1.31 以降を実行する新規および既存の Amazon EKS クラスターでサポートされています。Amazon EKS を利用できるすべての AWS 商用リージョン、AWS GovCloud (米国)、中国リージョンで、追加料金なしで利用できます。 horizontalPodAutoscalerSyncPeriod を使うには Provisioned Control Plane が必要で、Provisioned Control Plane にはスケーリング階層に応じた時間料金がかかります。 まとめ 高度な Kubernetes コントロールプレーン設定により、クラスター管理者は Amazon EKS の可用性とパフォーマンス特性を維持したまま、スケジューリング、リソース管理、API サーバーの設定を直接制御できます。お客様は、デフォルトの Kubernetes スケジューラを改変したものを実行したり、回避策を実装したりする必要がなくなり、運用オーバーヘッドを減らしながら、リソースの使用率を高め、コストを下げられます。この記事では、 MostAllocated のビンパッキングで Pod の配置を最適化してリソースの使用率を高め、イベントの保持期間を調整してデバッグのしやすさとストレージの効率のバランスを取りました。ぜひこの機能を使い始めて、 AWS Containers Roadmap でフィードバックをお寄せください。 使い始めるには、次の情報をご覧ください。 Amazon EKS ユーザーガイド で、高度な Kubernetes コントロールプレーン設定について確認してください。 コントロールプレーンのキャパシティを事前に割り当てる必要があるパラメータについては、 Amazon EKS Provisioned Control Plane の詳細をご覧ください。 ノードの管理を自動化してクラスターの運用を簡素化する Amazon EKS Auto Mode について、詳しくご覧ください。 翻訳はシニアパートナーソリューションアーキテクトの市川が担当しました。原文は こちら です。

本記事は 2026 年 10 月 27 日 に公開された「 Introducing time series collections for the next generation of Amazon OpenSearch Serverless 」を翻訳したものです。 本日、Amazon OpenSearch Serverless NextGen が時系列コレクションに対応したことを発表します。時系列コレクションを使えば、クラスターのプロビジョニングや管理をせずに、ログ、メトリクス、トレース、イベントデータを取り込み、保存、分析できます。時系列コレクションは取り込みのスパイクを自動で吸収し、直近のデータは高速にクエリでき、数か月から数年分の履歴も低コストで検索可能にします。これらすべてを同じコレクション内で実現します。時系列コレクションは OpenSearch Serverless にアラートと異常検知も追加するため、問題が起きた瞬間に発見して対処できます。コレクションあたり最大 100 TB のホットストレージをサポートし、アプリケーション監視、セキュリティ分析、IoT テレメトリなど大規模なオブザーバビリティワークロードに対応します。 オブザーバビリティデータは量が多く、不具合のあるデプロイや障害など、チームが最も早く答えを求める瞬間に急増します。クラスターのサイジングが不足すると処理が追いつかず、エンジニアが待っているログの到着が遅れるため、チームはピーク負荷に合わせてサイジングし、それ以外の日もその容量分を支払うことになります。履歴が増えるとホットストレージの費用がかさむため、保持期間を短縮したり、古いデータをスナップショットに移したりせざるを得ません。しかしスナップショットからクエリするには、まず誰かが復元する必要があります。クラスターには継続的なチューニングと容量計画も必要で、本来データが支援するはずの調査からエンジニアを引き離してしまいます。あらゆる判断がコスト、保持期間、システムへの疑問に答えるまでの速度のトレードオフになります。 OpenSearch Serverless の時系列コレクションはトレードオフを取り除きます。インシデントでログ量が急増しても、コンピュートが数秒でスケールして追従するため、エンジニアが待っているログは時間通りに届きます。トラフィックが落ち着けばコンピュートはゼロまでスケールダウンするため、ピーク時の容量に支払い続ける必要はありません。古いデータは低コストのウォーム層に移動しますがクエリは可能なので、保持期間を縮めたりスナップショットを復元したりせずに数年分の履歴を保てます。サイジングやチューニングが必要なクラスターはありません。コンピュートの上限といくつかのインデックス設定を指定すれば、あとはサービスが処理します。 クエリ頻度の低いデータは低コストで 時系列データへのクエリの大半は直近数時間から数日を対象としますが、古いデータはクエリ頻度こそ低いものの、引き続き利用可能にしておく必要があります。新しい index.warm.after 設定で、データがホット層に留まる期間を指定し、低コストのウォーム層へ移動するタイミングを決められます。日単位または時間単位で指定でき、最小 1 日 ( 24h または 1d ) から最大 10 年 ( 3650d ) までの範囲で、インデックスの保持期間を超えることはできません。未指定の場合、データは 1 日後にウォーム層へ移動します。 PUT /app-logs { "settings": { "index.warm.after": "7d" } } 取り込み時、各ドキュメントは低レイテンシーのホット層と Amazon Simple Storage Service (Amazon S3) の両方に書き込まれます。データが指定した経過期間に達すると、古いものから順にホットコピーが解放され、データは Amazon S3 上のウォーム層に残ります。クエリでウォーム層のデータが必要になると、サービスがそのデータをホット層に読み戻して処理します。該当データへの最初のクエリは時間がかかりますが、同じデータへの以降のクエリはホット層のレイテンシーで実行されます。古いデータに対する調査やレポート作成のように、同じ時間範囲を繰り返しクエリする用途に適しています。クエリが両方の層にまたがる場合も、結果は 1 つのレスポンスで返ります。ホットストレージの料金は、ホット層に残っているデータ分だけ発生します。 図 1: データは 7 日後にホット層からウォーム層へ移動し、全期間を通じて Amazon S3 に永続化される ワークロードが必要とする期間だけデータを保持 保持期間はインデックス自体に設定するため、別途ライフサイクルポリシーを作成・維持する必要はありません。インデックステンプレートで index.data.retention を設定すれば、パターンに一致するすべてのインデックスがその設定を継承します。1 日から 3,650 日 (10 年) までの範囲で、日数の整数で指定します。 PUT /_index_template/app-logs { "index_patterns": ["app-logs*"], "template": { "settings": { "index.data.retention": "30" } } } 階層管理と保持期間は独立しています。階層管理はクエリ速度とコストを制御し、保持期間はデータが削除されるタイミングを制御します。たとえばアプリケーションログは 7 日間ホット層に置いて 30 日間保持する、あるいはコンプライアンス要件に合わせて監査データを数年間ウォーム層に残す、といった運用が可能です。監査が必要になったら、同じコレクション内で履歴をクエリするだけで、検索コンピュートが追加負荷に合わせてスケールアップします。スナップショットの復元も、調査用クラスターの立ち上げも不要です。 図 2: データの階層管理と保持期間 インデックスごとにイベントタイムスタンプを指定 時系列コレクション内のすべてのドキュメントには、タイムスタンプフィールドが必須になりました。各インデックスには、サービスがデータの整理とソートに使う時刻フィールドが 1 つ指定されており、タイムスタンプが欠落、null、または無効なドキュメントは拒否されます。 デフォルトの時刻フィールドは @timestamp です。イベントが event_time のような別のフィールドをすでに持っている場合は、インデックス作成時またはインデックステンプレートで index.timestamp_field を設定すれば、プロデューサー側を変更せずに済みます。フィールドはトップレベルの date フィールドである必要があり、ドキュメントのタイムスタンプはインデックス登録後に変更できません。 PUT /app-logs { "settings": { "index.timestamp_field": "event_time" } } 拒否はドキュメント単位で、リクエスト全体には及びません。 _bulk リクエストでは有効なドキュメントはインデックス登録され、拒否されたドキュメントはレスポンスの errors ブロックに列挙されるため、1 件の不正レコードでバッチ全体が失敗することはありません。 図 3: 時刻フィールドが各ドキュメントのインデックス登録または拒否を決める仕組み 障害に発展する前に問題を見つける 時系列コレクションではアラートと異常検知も使えるようになりました。従来の Classic サーバーレスコレクションでは提供されていなかった機能です。別のシステムに頼って不具合を知らせてもらう代わりに、データを保存しているコレクション自体で監視、検知、通知ができます。運用チームはエラー率やレイテンシーの急増時に通知を受け取れ、セキュリティチームはログイン失敗の急増を検知でき、ビジネスチームは注文数の急落を発見できます。 アラートモニターはスケジュールに従ってデータをクエリし、条件が満たされると選択したチャネルを通じて通知します。Per-query モニターは、平均レイテンシーがしきい値を超えるなど、単一の値に対してアラートを発します。Per-bucket モニターは、エラー率が上がりすぎたホストごとなど、グループを個別に評価します。PPL モニターは Piped Processing Language (PPL) で、より複雑なロジックを扱えます。 異常検知は Random Cut Forest (RCF) 機械学習アルゴリズムでデータの通常パターンを学習し、固定しきい値を推定することなく、ほぼリアルタイムで逸脱を検出します。検出器の結果にモニターを向けておけば、異常が現れた瞬間に通知を受け取れます。 モニターと検出器は OpenSearch UI ワークスペースで管理し、アクセス権はワークスペースのコラボレーター権限に従います。読み取り専用のコラボレーターはモニターとアラートを閲覧でき、読み書きおよび管理者のコラボレーターは作成、更新、確認応答も可能です。Observability ワークスペースではアラートがダッシュボードや PPL クエリと並んで配置されるため、サーバーレスコレクションや既存の Amazon OpenSearch Service ドメインを横断して、アラートから背後のイベントまでたどれます。 使ってみる ワンクリックで始めるなら、Amazon OpenSearch Service コンソールの Express Create を使います。コレクショングループ、暗号化、ネットワークアクセス、データアクセスを自動で設定してくれます。各ステップを自分で制御したい場合は、以下のように AWS Command Line Interface (AWS CLI) を使います。 図 4: Express Create がデフォルト設定でコレクショングループ、暗号化、ネットワークアクセスを設定する様子 まず、NextGen のコレクショングループを作成します。コレクショングループは、所属するすべてのコレクションで共有するコンピュート上限を設定します。OpenSearch Compute Unit (OCU) の最小値を 0 にすれば、アイドル時にグループをゼロまでスケールダウンでき、最大値で支出に上限を設けられます。 aws opensearchserverless create-collection-group \ --name app-logs-group \ --generation NEXTGEN \ --standby-replicas ENABLED \ --capacity-limits '{ "minIndexingCapacityInOCU": 0, "minSearchCapacityInOCU": 0, "maxIndexingCapacityInOCU": 96, "maxSearchCapacityInOCU": 96 }' 次に、コレクションへアクセスできる場所を制御する ネットワークポリシー と、どの AWS Identity and Access Management (IAM) プリンシパルがデータを読み書きできるかを制御する データアクセスポリシー を作成します。 続いて、コレクショングループ内に時系列コレクションを作成します。 aws opensearchserverless create-collection \ --name app-logs \ --type TIMESERIES \ --collection-group-name app-logs-group \ --encryption-config aWSOwnedKey=true コレクションがアクティブになったら、時刻フィールド、階層管理、保持期間の設定を含むインデックステンプレートをワークロードに合わせて作成します。名前がパターンに一致するすべてのインデックスが、以下の設定を自動で引き継ぎます。 PUT /_index_template/app-logs { "index_patterns": ["app-logs*"], "template": { "settings": { "index.timestamp_field": "event_time", "index.warm.after": "7d", "index.data.retention": "30" } } } 最後にデータをコレクションに取り込み、OpenSearch UI の Observability ワークスペースを開いて、最初のダッシュボード、モニター、異常検出器を作成します。 本日提供開始 時系列コレクションは、NextGen の OpenSearch Serverless が利用可能なすべての AWS 商用リージョン で本日から提供されます。料金は OCU 単位で使用したコンピュートと、GB 月単位のホットおよびウォームストレージに対して発生します。詳細は Amazon OpenSearch Service 料金ページ をご覧ください。 詳しくは、 Amazon OpenSearch Serverless 製品ページ と Amazon OpenSearch Serverless 開発者ガイド を参照してください。 Amazon OpenSearch Service コンソール でぜひお試しいただき、 AWS re:Post または普段ご利用の AWS サポート窓口からフィードバックをお寄せください。 著者について Kevin Fallis Kevin はベテランのリーダー、アーキテクト、デベロッパーで、農業、アドテック、金融サービス、ネットワーキング、セキュリティ、通信、そしてもちろん検索技術など、さまざまな業界と専門領域での経験を持ちます。顧客がビジネス目標を達成できるよう、AWS サービスとオープンソースソリューションの適切な組み合わせを引き出すことに情熱を注いでいます。仕事以外では、家族と過ごす時間、DIY プロジェクト、大工仕事、乗馬、ドラム演奏、音楽全般を楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

はじめに こんにちは。クラウドエース株式会社 CTO室の関根です。 Cloudflareが公開した判断モデルClefをGoogle CloudのCloud Run GPU上で動かし、ブラウザから画像判定を試せるデモアプリ「Clef画像判定ラボ」を作りました。31ケース・35問の能力チェックを実施し、回答・確信度・応答時間を確認しました。 本記事では、Clefが型付きの判断を返す仕組み、アプリの構成、能力チェックの結果を説明します。Cloud Run GPUを選んだ理由と、起動時のモデル転送で分かったことも紹介します。 対象読者は、型付きの判断や確率を業務アプリに組み込みたいエンジニア