AWS Summit Japan 2026 参加レポート

こんにちは。ファインディのPlatform開発チーム（以降、SREチーム）でSREを担当している原（こうじゅん）、富田（@Cooking_ENG）、松本（@mozumasu）です。

2026年6月25日・26日に幕張メッセで開催された「AWS Summit Japan 2026」に、SREチームの3名で参加してきました。

aws.amazon.com

それぞれが印象に残ったセッションを1本ずつ取り上げ、ファインディの現状と紐づけてお届けします。

スタートアップに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万人規模で配信した際の裏側を紹介する内容でした。

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