Kubernetes コントロールプレーンのアップグレードは、長い間、一度行うと元に戻せないものでした。オープンソースの Kubernetes はコントロールプレーンのロールバックをサポートしていないため、一度アップグレードしたら後戻りはできません。コミュニティはここまで大きな進歩を遂げており、 KEP-4330 ではロールバックを容易にするためにエミュレートされたバージョンが導入されています。しかし実際には、この制約により、組織はベイク期間、スタッガーグループ、自動サインオフ、数か月にわたるアップグレードサイクルなど、精巧な補償メカニズムを構築する必要に迫られています。Kubernetes は年に 3 つのマイナーバージョンをリリースしているため、特に規制の厳しい環境では、何百ものクラスターを管理しているチームは、何か問題が発生した場合に回復できる自信がないために、アップグレードを完全に延期することがよくあります。その結果、クラスターは古いバージョンで行き詰まり、セキュリティパッチが適用されず、最終的にはサポート期間の延長に直面することになります。 2026 年 7 月 1 日、 Amazon Elastic Kubernetes Service (Amazon EKS) の Kubernetes バージョンロールバック についてお知らせします。これは、クラスター管理者がクラスターのアップグレードを実行する際のセーフティネットを提供する新機能です。バージョンロールバックを使用すると、アップグレード後に問題が発生した場合に 7 日以内に Kubernetes バージョンのアップグレードを取り消して、クラスターを以前の動作状態に戻すことができます。 エミュレートされたバージョンのようなアプローチではクラスターが過渡的な保持状態に保たれるのに対し、EKS バージョンロールバックはクラスターをエミュレートしたものではなく、本番環境で実行されていた完全に検証済みの以前のバージョンに戻します。これで、クラスターを例えば Kubernetes 1.34 から 1.35 にアップグレードして互換性の問題が見つかった場合、7 日以内に 1.34 にロールバックできます。クラスターを再構築したり、プレッシャーのかかる状況でトラブルシューティングを急いだりする必要はありません。Kubernetes のバージョンアップグレードの [元に戻す] ボタンと考えてください。 この機能は、EKS がアップグレードに使用するのと同じインクリメンタルアプローチに合わせて、一度に 1 つのマイナーバージョンにロールバックすることをサポートします。また、安全にロールバックできるように、EKS は クラスターインサイト を通じてクラスターのロールバック準備状況を自動的に評価し、処理を進める前にノードバージョンの互換性やアドオンの依存関係などの項目にフラグを付けます。状況をすでに評価していて、迅速に行動したい場合は、 --force フラグを使用してこれらのチェックをバイパスできます。上記は、独自のノードを管理する場合でも、AWS に処理させる場合でも、すべての EKS クラスターに適用されます。しかし、フルマネージドインフラストラクチャを採用しているお客様にとっては、ロールバックはさらに一歩進んだものです。 EKS Auto Mode のロールバック EKS Auto Mode では、本番環境に対応した Kubernetes クラスターをワンクリックでデプロイし、コンピューティング、ネットワーキング、ストレージの管理を自動化できるため、インフラストラクチャではなくアプリケーションに集中できます。EKS Auto Mode では、コントロールプレーンとマネージドノードの両方を同時にロールバックする必要があるため、 バージョンロールバック に関する追加の考慮事項があります。ノードのロールバックはポッドの中断バジェットを考慮しているため、設定によってはプロセスに時間がかかる場合があります。 このプロセスを制御できるように、どの時点でもノードのロールバックを停止できる キャンセル API を導入しました。ロールバックに時間がかかりすぎると判断した場合、またはアプローチを変更したい場合は、キャンセルして中断バジェットを調整して物事を加速させるか、別の今後の進め方を選択することができます。 デフォルトでは、EKS はワークロードの安定性を優先するため、ロールバック中に中断バジェットをバイパスすることはありません。必要に応じていつでも中断バジェットを自分で変更したり削除したりして、プロセスをスピードアップできます。 試してみましょう バージョンロールバックを試すために、Amazon EKS コンソールに移動し、最近アップグレードした私のクラスターの 1 つを選択しました。 クラスターの設定ページから、バージョンロールバックを開始するオプションと、現在のロールバックウィンドウに関する情報が表示されます。 ロールバックを開始する前に、ロールバックのインサイトを確認して、潜在的な問題がないかどうかを確認しました。インサイトにより、私のノードの状態がわかり、先に進む前に対処すべき点にフラグが付けられました。 確認後、ロールバックが開始されました。私のクラスターはプロセス全体を通して機能し続けました。コントロールプレーンのロールバックには、標準のアップグレードと同様に約 20 分かかりました。私の EKS Auto Mode クラスターでは、中断バジェット設定に従ってノードが正常にロールバックされました。 完了すると、私のクラスターは前の Kubernetes バージョンに戻り、期待どおりに動作しました。 今すぐご利用いただけます Amazon EKS の Kubernetes バージョンロールバック は、Amazon EKS が利用可能なすべての商用 AWS リージョンで、追加料金なしで今すぐご利用いただけます。通常発生する標準の EKS とコンピューティングコストのみをお支払いいただきます。ロールバック機能を使用しても、追加料金は発生しません。 コントロールプレーンのロールバックはすべての EKS クラスターで使用でき、ノードのロールバックは EKS Auto Mode を実行しているクラスターで使用できます。バージョンロールバックは、EKS 標準サポートと延長サポートで利用可能な Kubernetes バージョンを実行しているクラスターをサポートします。 開始するには、 Amazon EKS のドキュメント を参照するか、 Amazon EKS コンソール で直接試してみてください。 原文は こちら です。

本記事は 2025 年 9 月 22 日 に公開された「 A scalable, elastic database and search solution for 1B+ vectors built on LanceDB and Amazon S3 」を翻訳したものです。 この記事は Metagenomi の Owen Janson、Audra Devoto、Christopher Brown との共著です。 CRISPR によるゲノム編集から産業用バイオ触媒まで、酵素はヘルスケア、エネルギー、製造業における変革的な技術を支えています。しかし、ゲノム工学における Cas9 のように産業を変えるような新規酵素を発見するには、生命の系統樹にまたがる膨大な生物がコードする数十億種類の酵素を探索しなければなりません。DNA シーケンシングとメタゲノミクスの進歩により既知のタンパク質配列を格納した大規模な公開・独自データベースが構築されてきましたが、そこから価値の高い候補を見つけ出すのは生物学の問題であると同時にビッグデータの問題でもあります。 Metagenomi では、独自の大規模メタゲノミクスデータベース (MGXdb) を活用し、新規遺伝子編集システムのツールボックスを構築することで、根治的な治療法の開発に取り組んでいます。この記事では、Metagenomi が Amazon Web Services (AWS) のスケーラブルなインフラを使い、エンベディングに基づく高性能タンパク質データベースと検索ソリューションを構築して、数十億タンパク質規模の酵素発見に挑んでいる方法を紹介します。独自の大規模データベースに含まれるすべてのタンパク質をベクトル空間にエンベディングし、 Amazon Simple Storage Service (Amazon S3) 上に構築した LanceDB でデータにアクセスできるようにして、 AWS Lambda で検索することで、酵素発見を最近傍探索問題に変換し、これまで未探索だった発見空間に高速にアクセスできるようになりました。 ソリューション概要 このソリューションの中心にあるのが LanceDB です。LanceDB はオープンソースのベクトルデータベースで、インデックス付きベクトルに対する高速な近似最近傍 (ANN) 検索を実現します。LanceDB は完全にファイルベースで Amazon S3 ストレージとも互換性があるため、サーバーレス構成に適しています。その結果、エンベディング済みタンパク質配列のデータベースを Amazon Elastic Block Store (Amazon EBS) のような永続ディスクではなく、比較的低コストな Amazon S3 に保存できます。常時稼働するサーバーは不要で、データベースをオンデマンドで検索するのに必要なのは、LanceDB を使って S3 上のデータから直接最近傍を見つける Lambda 関数だけです。 Metagenomi の大規模タンパク質データベースを表す数十億のベクトルエンベディングを取り込み・検索するために、データベースを均等なサイズのパーツ (フォルダ) に分割して Amazon S3 に低コストで保存し、それらを並列にインデックス化して Lambda による map-reduce アプローチで検索する方法を考案しました。以下の図がこのアーキテクチャを示しています。 処理は 4 つのステップで構成されています。 データのベクトル化 データのバケット分割 データの取り込みとインデックス作成 データベースへのクエリ データのベクトル化 LanceDB の高速な ANN 検索機能を利用するには、データをベクトル形式にする必要があります。Metagenomi のメタゲノミクスデータベースには数十億のタンパク質が含まれており、それぞれがアミノ酸の文字列です。各タンパク質を生物学的に意味のある情報を捉えたベクトルに変換するため、タンパク質言語モデル (pLM) に通し、モデルの隠れ層をそのタンパク質のベクトル表現として取得します。タンパク質エンベディングの生成にはさまざまな pLM が使用でき、求める生物学的情報と計算要件に応じて選択します。今回は AMPLIFY_350M モデル を使用しました。データベース全体へのスケーリングに十分な速度を持つ Transformer エンコーダモデルです。モデルの最終隠れ層に対して mean-pool を実行し、各タンパク質について 960 次元のベクトルを生成します。生成されたベクトルと対応する一意のタンパク質 ID は HDF5 ファイルに保存します。 データのバケット分割 タンパク質ベクトルを検索可能なデータベースにするために、LanceDB でクエリの ANN を高速に見つけるためのインデックスを構築します。しかしインデックス作成には時間がかかり、複数ノードへの分散も困難です。インデックス作成を高速化するため、まずデータをほぼ均等なサイズのバケットに分割します。エンベディング HDF5 ファイルを best-fit bin packing アルゴリズムで合計約 2 億ベクトルのバケットに割り当てます。バケット分割に使う具体的なサイズ決定方法は、ベクトルの数、次元数、フォーマットによって異なります。各バケットは Amazon S3 上の単一の LanceDB データベースオブジェクトストア内に独立したテーブルとして取り込まれます。 データをバケット分割することで、個別ノードで並列にインデックス化できる小さなデータベースを複数作成でき、インデックス作成時間を大幅に短縮できます。また、既存データ全体を再インデックスする代わりに、新しいバケットとしてデータを追加でき増分追加も容易です。 バケット分割データの取り込みとインデックス作成 ベクトル化されたデータがバケットに割り当てられたら、LanceDB テーブルに変換してインデックスを作成し、高速な ANN クエリを可能にします。データを LanceDB テーブルに変換する具体的な方法は LanceDB のドキュメント を参照してください。約 2 億ベクトルの各バケットに対して、コサイン距離の IVF-PQ インデックスを持つ LanceDB テーブルを作成します。インデックス作成では、パーティション数は挿入行数の平方根、サブベクトル数はベクトル次元数を 16 で割った値を使用します。 クエリをスムーズにするため、各テーブルは作成元のバケットにちなんだ名前を付け、単一の S3 ディレクトリにアップロードします。ファイル構造から見ると、複数テーブルを持つ 1 つの LanceDB データベースとして認識されます。 以下のコードスニペットは、 id カラムと embedding カラムを含む HDF5 ファイルからベクトルを LanceDB データベースに取り込み、コサイン距離による高速 ANN 検索用にインデックスを作成する例です。実行に必要なのは python >= 3.9 と lancedb 、 pyarrow 、 h5py パッケージです。このスニペットは非同期 LanceDB API を使用する lancedb バージョン 0.21.1 でテスト・開発されています。 from typing import List, Iterable from itertools import islice from math import sqrt import pyarrow as pa import datetime import asyncio import lancedb import h5py def batched(iterable: Iterable, n: int) -> Iterable[List]: """Yield batches of n items from iterable.""" while batch := list(islice(iterable, n)): yield batch async def vectors_to_db( vectors: str, db: str, table_name: str, vector_dim: int, ingestion_batch_size: int, ) -> int: """Ingest and index vectors from an HDF5 file into a LanceDB table. Args: vectors (str): An HDF5 file containing protein IDs and their 960-dimension vector representations. db (str): Path to the LanceDB database. table_name (str): Name of the table to create. vector_dim (int): Dimension of the vectors. """ # create db and table custom_schema = pa.schema( [ pa.field("embedding", pa.list_(pa.float32(), vector_dim)), pa.field("id", pa.string()), ] ) # count the total number of rows as they are added to the table total_rows = 0 # open a connection to the new database and create a table with await lancedb.connect_async(db) as db_connection: with await db_connection.create_table( table_name, schema=custom_schema ) as table_connection: # open vectors file with h5py.File(vectors, "r") as vectors_handle: # create a generator over the rows rows = ( {"embedding": e, "id": i} for e, i in zip( vectors_handle["embedding"], vectors_handle["id"], ) ) # insert rows in batches to avoid memory issues for batch in batched(rows, ingestion_batch_size): total_rows += len(batch) await table_connection.add(batch) # optimize the table and remove old data await table_connection.optimize( cleanup_older_than=datetime.timedelta(days=0) ) # configure the index for the table index_config = lancedb.index.IvfPq( distance_type="cosine", num_partitions=int(sqrt(total_rows)), num_sub_vectors=int( vector_dim / 16 ), ) # index the table await table_connection.create_index( "embedding", config=index_config ) # ingest and index your data asyncio.run( vectors_to_db( vectors="./my_vectors.h5", db="./test_db", table_name="bucket1", vector_dim=960, ingestion_batch_size=50000 ) ) ベクトル化、取り込み、各バケットのインデックス作成は、複数の AWS Batch ジョブで並列実行することも、単一の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで実行することもできます。 データベースへのクエリ データがバケット分割され Amazon S3 上の LanceDB データベースに取り込まれたら、クエリの手段が必要です。LanceDB は LanceDB Python API を使って Amazon S3 から直接クエリできるため、Lambda 関数でユーザーが指定したクエリベクトルを受け取り、ANN を検索して結果を返すことができます。ただし、データが複数テーブルにバケット分割されているため、各バケットで最近傍を検索し、結果を集約してからユーザーに返す必要があります。 クエリワークフローは AWS Step Functions の ステートマシン として実装しています。各バケットに対するクエリ処理を Lambda プロセスとして管理し、最後に単一の Lambda プロセスがデータを集約して結果の ANN を .csv ファイルとして Amazon S3 に書き込みます。AWS Batch プロセスやローカル実行でも代替可能です。以下のスニペットは、1 つのバケットに対して ANN クエリを実行するプロセスの例です。実行に必要なのは python >= 3.9 と pandas 、 lancedb パッケージです。取り込みセクションと同様に、非同期 LanceDB API と lancedb バージョン 0.21.1 を使用しています。 from typing import List, Iterable import asyncio import lancedb import pandas import random async def run_query_async( lancedb_s3_uri: str, table_name: str, q_vec: List[float], k: int, vec_col: str, n_probes: int, refine_factor: int, ) -> pandas.DataFrame: """Run a query on a LanceDB table. Args: lancedb_s3_uri (str): S3 URI of the LanceDB database. table_name (str): Name of the table to query. q_vec (List[float]): Query vector. k (int): Number of nearest neighbors to return. vec_col (str): Column name of the vector column. n_probes (int): Number of probes to use for the query. refine_factor (int): Refine factor for the query. Returns: pandas.DataFrame: DataFrame containing the approximate nearest neighbors to the query vector. """ # open a connection to the database and table with await lancedb.connect_async( lancedb_s3_uri, storage_options={"timeout": "120s"} ) as db_connection: with await db_connection.open_table(table_name) as table_connection: # query the approximate nearest neighbors to the query vector df = ( await table_connection.query() .nearest_to(q_vec) .column(vec_col) .nprobes(n_probes) .refine_factor(refine_factor) .limit(k) .distance_type("cosine") .to_pandas() ) return df # query the example bucket we produced in the last section bucket1_df = asyncio.run( snippets.run_query_async( lancedb_s3_uri="s3://mg-analysis/owen/20250415_lancedb_snippet_testing/test_db/", table_name="bucket1", q_vec=[random.random() for _ in range(960)], k=3, vec_col="embedding", n_probes=1, refine_factor=1, ) ) 上記のクエリは以下の構造を持つ pandas DataFrame を返します。 embedding id _distance [-5.124435, 4.242000, …] id_1 0.000000 [-5.783999, 4.340500, …] id_2 0.001000 [-6.932943, 3.394850, …] id_3 0.04020 embedding カラムには最近傍のベクトル表現、 id カラムにはその ID、 _distance カラムにはクエリベクトルとのコサイン距離が格納されています。 各バケットが個別のノードで検索され、それぞれが最近傍の DataFrame を返した後、結果をマージしてユーザーに返す必要があります。以下のスニペットはその方法の例です。 def aggregate_nearest_neighbors( dfs: List[pandas.DataFrame], k: int ): """Aggregate the nearest neighbors for each query vector. Args: dfs (List[pandas.DataFrame]): A list of DataFrames containing the nearest neighbors queried from each bucket. k (int): The number of nearest neighbors to aggregate. Returns: pd.DataFrame: A DataFrame with the aggregated nearest neighbors. """ # concatenate the DataFrames and get the top k nearest neighbors return ( pandas.concat(dfs, ignore_index=True) .sort_values(by=["_distance"], ascending=True) .reset_index(drop=True) .head(k) ) # add the dataframes from querying each bucket to a list dfs = [bucket1_df, bucket2_df, bucket3_df, bucket4_df, bucket_5] # aggregate the nearest neighbors across all buckets nearest_neighbors_all_buckets_df = aggregate_nearest_neighbors(dfs, 5) 大量クエリの最適化 Lambda で S3 上の LanceDB データベースを直接検索する方法は、1 つまたは少数のクエリベクトルの ANN 検索には適していますが、数千から数百万のベクトルをクエリする必要があるユースケースもあります。 大量クエリに対してスケールする方法として、先述のクエリ実装を変更し、まずデータベースのバケットの 1 つをローカルストレージにダウンロードしてから LanceDB API でローカルに検索する方式を採用しています。データベースバケットのストレージサイズが大きいため、この実装は Lambda よりも AWS Batch ジョブに適しており、EBS ボリュームではなく最適化されたインスタンスストレージ (例: i4i インスタンス) の使用を推奨します。すべてのクエリ Batch ジョブが完了した後、最終ジョブが結果を集約してからユーザーに返します。並列クエリジョブと集約ジョブのオーケストレーションには Nextflow が使用できます。バケットをディスクにダウンロードするオーバーヘッドとレイテンシーは増加しますが、大量のクエリをより効率的に処理でき、常時稼働のサーバーベースデータベースも不要です。 ベンチマーク結果 インデックス戦略やデータベース分割サイズは、求めるパフォーマンスに依存します。ユースケースに合わせてカスタマイズする際の一般的な最適化ガイダンスを以下に示します。 Metagenomi が作成したデータベースの例では、AMPLIFY で生成した 960 次元のベクトルエンベディング 35 億件を格納しています。この 35 億ベクトルエンベディングを 2 億ベクトルごとに分割し、 i4i.8xlarge インスタンスで取り込みとインデックス作成を行ったところ、合計 108 コンピュート時間で完了しました。このソリューションはサーバーレスで S3 オブジェクトストアから直接クエリできるため、データベースの固定コストは Amazon S3 上のストレージ容量のみです (35 億ベクトルのインデックス済みデータベースで約 12.9 TB)。Lambda によるクエリは非常に低コストで、多くのクエリが 1 セント未満で実行できます。 一般的に、分割サイズが大きいほどクエリのコスト効率は高くなりますが、実行時間とインデックス作成時間は長くなります。単一分割で許容可能なクエリ応答時間を維持できる最大サイズまでスケールアップし、同時に Lambda 同時実行数の上限などの並列化の制約も考慮することを推奨します。Metagenomi では 2 億ベクトルごとの分割が、小規模・大規模両方のクエリでコストと実行時間の最適なバランスを示しました。取り込みとインデックス作成には i4i ファミリーなどのストレージ最適化インスタンスの使用を推奨します。ディスクベースのデータベースでクエリを実行する場合 (Lambda + Amazon S3 ではなく) も、ストレージ最適化インスタンスの使用を推奨します。Lambda 実装では、最大 50,000 ANN を要求する単一クエリ、または 5 ANN 未満で最大 100 シーケンスのマルチクエリを素早く処理できました。以下のグラフに示すように、実行時間は要求する ANN 数に対して線形に増加します。 まとめ この記事では、Metagenomi が LanceDB を Amazon S3 と AWS Lambda 上に実装し、数十億のタンパク質エンベディングを低コストで保存・検索する方法を紹介しました。この取り組みは、Metagenomi が根治的な遺伝子治療の開発に向けて推進する、新規酵素の発見とエンジニアリングプラットフォームの加速に貢献しています。クエリタンパク質の ANN エンベディング空間に数秒でアクセスできるようになったことで、大規模な解析パイプラインに高速検索手法を統合し、多様で新規な酵素ファミリーの発見を加速し、研究者がエンベディングをオンザフライで生成・検索する手段を提供してタンパク質エンジニアリングの取り組みを可能にしています。Metagenomi がタンパク質・DNA データベースの急速な拡大を続ける中、並列にインデックス化・検索できるデータベース分割による水平スケーリングが、将来のニーズに対応するエンベディングデータベースソリューションを実現しています。 この記事で紹介したソリューションはタンパク質 大規模言語モデル (LLM) で生成したベクトルに焦点を当てていますが、他のベクトル化されたデータセットにも適用できます。Amazon S3 と統合した LanceDB の詳細は LanceDB のドキュメント を参照してください。 参考文献 Fournier, Quentin, et al. “Protein language models: is scaling necessary?.” bioRxiv (2024): 2024-09. 著者について Audra Devoto Audra はメタゲノミクスのバックグラウンドを持つデータサイエンティストで、AWS 上の大規模ゲノミクスデータセットの取り扱いに長年の経験があります。Metagenomi では大規模解析プロジェクトを支えるインフラを構築し、MGXdb からの新規酵素発見を推進しています。 Christopher Brown Christopher Brown 博士は Metagenomi の Discovery チーム責任者です。メタゲノミクスの専門家であり、遺伝子編集応用に向けた多数の新規酵素システムの発見と特性解析を主導してきました。 Patrick O’Connor Patrick は AWS のシニア WorldWide AI プロトタイピングエンジニアで、クラウド上で生成 AI ソリューションとエンドツーエンドのプロトタイプを構築しています。大規模言語モデルと分散 AI システムの実装を専門としており、IoT、サーバーレス技術、ハイパフォーマンスコンピューティングの知見を活かして企業の複雑な課題解決に取り組んでいます。 Owen Janson Owen は Metagenomi のバイオインフォマティクスエンジニアで、大規模ゲノミクスデータセットの解析を支えるツールとクラウドインフラの構築に注力しています。 Pavel Novichkov Pavel Novichkov 博士は AWS のシニアソリューションアーキテクトで、ゲノミクスとライフサイエンスを専門としています。15 年以上のバイオインフォマティクスとクラウド開発の経験を持ち、ヘルスケア・ライフサイエンス分野のスタートアップが AWS 上でクラウドベースのソリューションを設計・実装する支援を行っています。NIH の National Center for Biotechnology Information でポスドク研究を行い、Berkeley Lab で 12 年以上計算研究科学者として勤務しました。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

こんにちは。ファインディのPlatform開発チーム（以降、SREチーム）でSREを担当している原（ こうじゅん ）、富田（ @Cooking_ENG ）、松本（ @mozumasu ）です。 2026年6月25日・26日に幕張メッセで開催された「AWS Summit Japan 2026」に、SREチームの3名で参加してきました。 aws.amazon.com それぞれが印象に残ったセッションを1本ずつ取り上げ、ファインディの現状と紐づけてお届けします。 スタートアップにAmazon EKSは早すぎる？ マルチプロダクト戦略を加速するPlatform Engineeringの実践 TBSテレビ「ラヴィット！」大規模配信の裏側とAWSサーバーレス設計 実践！Amazon RDSとAmazon Auroraのコスト最適化とパフォーマンス向上 まとめ スタートアップにAmazon EKSは早すぎる？ マルチプロダクト戦略を加速するPlatform Engineeringの実践 SREチームの 原 です。 私が印象的だったのは、株式会社ログラスの中井綾一さんによるセッション「スタートアップにAmazon EKSは早すぎる？ マルチプロダクト戦略を加速するPlatform Engineeringの実践」です。 ファインディはECSを中心に構成していますが、今後Platformをどのようにしていくかという判断軸を持ち帰りたいと考え、このセッションに参加しました。 ログラスは経営管理サービス「Loglass」を中心にマルチプロダクト戦略を進めている会社で、本セッションではAmazon EKSをベースにしたPlatform基盤の導入から、1年で社内に広げていくまでの実践が紹介されました。 中井さんがEKS導入を判断した時点でのチーム規模は、次の通り紹介されていました。 エンジニア約50名 プロダクト2つ SREチーム4名 「マルチプロダクト戦略・SRE4名」という条件で、なぜ「重い」と言われがちなEKSを選んだのか、というのが本セッションの主題でした。 特に印象に残ったのは、技術選定の軸として中井さんが繰り返し言い切っていた「『今の規模』ではなく『数年後の事業にフィットするか』で判断する」という言葉でした。 基盤選定をする際には、「現時点で十分」「今の人数で運用できる」という現在地ベースになりがちですが、中井さんからはPlatform構築は1〜2年かかる長期投資で、課題が顕在化してから着手したのでは間に合わない、というメッセージが繰り返されていました。 実際に、SRE4名で導入を進めたPlatform基盤上で、1年で5チーム・約20サービスまで展開されたとのことです。 もう1つ刺さったのが「AI時代だからこそEKSプラットフォームに価値がある」という主張です。Coding Agentが高速に変更を生む時代には、Namespace分離・RBACやAdmission Controllerによってチーム・サービスごとの権限境界やポリシーを機械的に担保でき、開発効率と品質・統制を両立できる、という観点でした。 ここで気になるのが、ファインディの現在地です。 ファインディは現在、マルチプロダクト展開、SREチーム4名、基盤はAmazon ECS中心で、インフラ構築はTerraform汎用モジュールを介して開発者主体で進められる体制を整えてきました。 tech.findy.co.jp 直近のSREチーム全体の取り組みは、次のFindy Tech Talkでも紹介しています。 tech.findy.co.jp マルチプロダクトと開発者主体での運用がさらに広がったときに、SREチームがボトルネックにならないPlatformの形をどう先回りで仕込むかの重要性を感じました。「事業に対してPlatformをどう先回りで仕込むか」という考え方は大変勉強になりました。 TBSテレビ「ラヴィット！」大規模配信の裏側とAWSサーバーレス設計 SREチームの 富田 です。 私が参加したのは、株式会社TBSテレビの亀田遼さんによるブレイクアウトセッション「TBSテレビ『ラヴィット！』大規模配信の裏側とAWSサーバーレス設計」です。 『ラヴィット！忘年会 '25』を、想定視聴者数6万人規模で配信した際の裏側を紹介する内容でした。 全く宣伝できていませんでしたが、AWS Summitで初登壇しました！！ お聞きいただきありがとうございました🙏 #AWSSummit pic.twitter.com/PtQwcKdcxY — Ryo (@ry_km_u_u) 2026年6月25日 x.com 『ラヴィット！忘年会 '25』の配信プラットフォームには、KustamieというTBSテレビが開発している自社サービスが使われています。配信者と参加者の双方向なやりとりを充実させ、「参加感」を高めるためのイベント向けプラットフォームです。 アーキテクチャはサーバーレス中心で、データ管理にAmazon ECSとAmazon Aurora Serverless v2、クライアントAPIにAmazon API GatewayとAWS Lambda、映像とリアルタイム通信にAmazon IVS (Interactive Video Service) を利用しています。 大規模配信に向け、既存のクライアントAPI構成には次のような課題があったそうです。 キャッシュを前提とした構成になっていなかった 配信参加時のAPIレスポンスに最長12秒程度かかっていた 負荷試験を実施したことがなく、高負荷時の挙動が未知数だった これらの課題に対する解決策の中で、特に印象に残ったのが多段キャッシュ構成によるレスポンス改善のお話でした。 採用されたのは、Amazon API Gatewayのステージキャッシュ・AWS Lambda関数のグローバル変数・Amazon ECSと併設したAmazon ElastiCache (Valkey) を組み合わせた3層構成です。 API GatewayステージキャッシュでGET系レスポンスをエッジから返し、Lambdaのグローバル変数でホットスタート時の関数初期化を省き、ElastiCacheで後段のDBアクセスを軽くする、という形で多段にキャッシュが効くようにしていました。 結果として、最長12,000ms程度かかっていた配信参加時のAPIレスポンスが、平均150ms程度まで改善したそうです。 Amazon SQSとAWS Step Functions Expressによる非同期化も合わせて実施されており、設計全体で大きな改善幅が出ていました。 負荷試験にはOSSの負荷試験ツールGrafana k6が使われており、待機配信前→待機配信中→本編配信中の3フェーズで指数的にVUを増やすシナリオで本番のアクセスパターンを再現したそうです。 直近、私もk6とDatadogでファインディの負荷試験環境を構築していたところだったので、シナリオ設計や規模の見立てが自分の作業と重なって、特に身近に感じられた話題でした。 ファインディでの負荷試験環境構築の取り組みは次の記事で紹介しています。 tech.findy.co.jp 6万人規模の同時アクセスをサーバーレス中心の構成でさばく事例として、設計の引き出しを増やせたセッションでした。 ファインディでも「Findy Conference」を中心に瞬間的なアクセス集中は発生するため、「キャッシュをどの層で重ねるか」「どこを非同期に逃がすか」を設計初期から意識する姿勢は参考にしたい考え方でした。エッジ・Lambda・ElastiCacheで多段にキャッシュを効かせる発想は、今後の負荷特性の変化に備える引き出しとして持ち帰りたいと感じています。 また、Amazon IVSのように、ライブ配信向けに使えるAWSサービスをユースケースとセットで知れたことも収穫でした。 Kustamieは2026年秋にベータ版提供開始予定とのことです。どんなイベント体験が広がっていくのか、リリースが楽しみです。 実践！Amazon RDSとAmazon Auroraのコスト最適化とパフォーマンス向上 SREチームの 松本 です。 私が印象に残ったのは、アマゾン ウェブ サービス ジャパン合同会社の塚井知之さんによるブレイクアウトセッション「実践！Amazon RDSとAmazon Auroraのコスト最適化とパフォーマンス向上」です。 「パフォーマンス向上」と「コスト最適化」は両立できる、というテーマのもと、架空のEC支援企業「AnyCompany」が直面する課題と、その解決策を追体験していく構成のセッションでした。 AnyCompanyには「レポートクエリによる運用DBの圧迫」「複雑クエリでの一時オブジェクト書き出しによるI/Oボトルネック」「メモリに乗り切らないホットデータ」「バックアップコストの肥大化」といった、実務でよく遭遇する課題が並んでいました。 セッション全体で繰り返し問われていたのが、「大きいインスタンスへの垂直スケーリングは、最もコスト効率の良い選択か？」という問いです。 特に印象に残ったのが、垂直スケーリングに頼らずにコストとパフォーマンスを両立する3つのパターンでした。 リードレプリカへのクエリオフロード（レポートクエリを逃がす） RDS Optimized Reads（一時オブジェクトをローカルSSDに逃がす） Aurora Optimized Reads（バッファキャッシュをローカルSSDに拡張する） 1つ目は、リードレプリカへのクエリオフロードです。 社内データアナリストのレポートクエリが運用DBを圧迫している状況で、インスタンスを1段階上げる代わりに、小さめのリードレプリカを足してレポートを逃がす構成にすることで、約15%のコスト削減と顧客APIの安定化を同時に実現できる、という試算でした。 「先に分けることでむしろ安く済む」という発想は、Amazon RDSまわりの構成判断でも応用が効く話だと感じました。 2つ目は、RDS Optimized Readsで一時オブジェクトをローカルSSDに逃がすパターンです。 複雑なクエリで生成される一時オブジェクトがAmazon EBSに書き出されてレイテンシが伸びる、というボトルネックに対し、ローカルNVMe SSDを搭載したインスタンスへ載せ替えて一時ファイルの書き出し先をローカルSSDに切り替える、というアプローチでした。 垂直スケーリングと比べて約43%のコスト削減かつ最大2倍の読み取り性能向上というのは、知らないと選べない選択肢だと痛感しました。 3つ目は、Aurora Optimized ReadsでバッファキャッシュをローカルSSDに拡張するパターンです。 メモリに乗り切らないホットデータをディスクから読み直してしまう、というボトルネックに対し、ローカルNVMe SSDをバッファプールの第2階層として使う「階層型キャッシュ」で対処します。 同等のインメモリキャッシュを得るために大きなインスタンスに上げる代わりに、小さめのインスタンス + I/O-Optimizedの組み合わせを選ぶことで、約90%のコスト削減と最大8倍の読み取り性能を実現する事例でした。 判断のステップとして BufferCacheHitRatio や AuroraEstimatedSharedMemoryBytes でワーキングセットを把握してから選ぶ、という手順も合わせて示されており、「まず可視化してから手を打つ」という基本がここでも徹底されていたのが印象的でした。 バックアップ面でも、自動バックアップの保持期間を短くし、それより古い分はAmazon S3へのParquet形式スナップショットエクスポートに切り替えることで、30%のコスト削減ができるという試算が紹介されていました。 障害復旧のためのリストア要件は直近のデータで足りる一方、監査や過去データの参照は必ずしも即時のリストアを必要としないため、S3への安価なエクスポートに逃がせます。この「リストア要件」と「参照要件」を分けて考えるとコスト構造が大きく変わる、というのはファインディの運用でもすぐに見直せそうな観点です。 どの課題でも、Database InsightsやPerformance Insightsでまずワークロードを可視化し、ボトルネックに応じて適切なインスタンスファミリー・ストレージタイプ・キャッシュ階層を選び直す、という流れで進められていたのが印象的でした。 「見えないものは改善できない」という基本を、AnyCompanyの課題を通して追体験できる構成になっていたと感じました。 まずは BufferCacheHitRatio や VolumeReadIOPs ・ VolumeWriteIOPs を見直し、I/O-OptimizedやOptimized Readsが効くワークロードがないかを棚卸しするところから始めたいと思います。 まとめ 2日間を通して、各社の事例や最新サービスに直接触れられる濃いインプットの機会となりました。負荷試験のシナリオ設計や、Amazon RDS/Auroraのコスト最適化、マルチプロダクト時代のPlatformの形といった、現地で持ち帰った論点を、SREチームの日々の取り組みに少しずつ活かしていきます。 ファインディでは、SREメンバーを募集しています。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers