アソビューSREの2025年を振り返る

SRE EKS Monorepo モジュラモノリス

はじめに

この記事は、アソビュー Advent Calendar 2025の5日目（表面）です。
こんにちは。アソビューでSREを担当している @kassshi_dev です。

アソビューのSREは現在5名のメンバーで活動しています｡2025年にやってきたことをいくつかご紹介できればと思います｡

Istio Ambient Mesh モードの導入

背景

Kubernetes でチームごとの開発環境構築､Progressive Delivery などで実現したいことがいくつかあり､その手段としてIstioの導入を決めました｡ 2024年の後半から調査と検証を進めていましたが､Sidecar モードと Ambient Mesh モードの2つ選択肢がありました｡

下記理由で Ambient Mesh モードを採用しました｡

  • Istio リソースとアプリケーションリソースの管理やリリースサイクルを分離できる
  • パフォーマンスやリソース効率の観点で Sidecar モードよりもメリットがある
  • Istio が Ambient Mesh モードが今後のスタンダードになると言及している

困ったこと

ドキュメント不足

想定していましたが Ambient Mesh モードに関する事例､記事､ドキュメントは現状少ないです｡疎通確認、レイテンシ検証、Istioリソースの挙動確認などの小さな検証を繰り返し、Production Ready な構成に仕上げました｡

Ztunnelの仕様理解

Ztunnel とは Ambient Mesh モードにおけるL4レイヤーのProxyとして動く DaemonSet です｡

Ztunnel の詳細設定についてのドキュメントは充実しておらず､また現時点でユーザー側で Ztunnel の設定を変更する IF は用意されていません｡設定内容を把握するために､Ztunnel のエンドポイント /config_dump のレスポンスを参照することで理解を深めました｡例えばコネクション周りの設定などアプリケーション側と整合性をあわせる必要があるものについて､詳細まで把握する必要がありここが大きな苦労ポイントでした。

運用事例

Ztunnel の Idle Timeout は300s

Ztunnel の Idle Timeout が 300s のため、クライアント側が 300秒以上再利用するコネクションプールを持っていると、Ztunnel が先にコネクションを閉じてしまい不整合が発生します。

Ztunnel が破棄したコネクションをクライアントが再利用することを防止するために下記を実装しました｡ 現時点で Ztunnel の設定を変更するIFは用意されていないためクライアント側で対応する必要があります｡

  1. Client 側の Idle Timeout を300sより短くする(社内の共通ライブラリで配布)
  2. Client 側の処理にリトライが入っていない場合は追加する

Ztunnel の設定

{
  "config": {
    "poolUnusedReleaseTimeout": {
      "nanos": 0,
      "secs": 300
    },

Waypoint の柔軟な配置戦略

Waypoint は Ambient Mesh モードにおける L7 レイヤの Proxy(istio-proxy) です｡以下の単位でデプロイ可能です｡

  • Namespace
  • Service
  • Pod
  • Cross Namespace

Istio 公式はNamespace単位のデプロイから開始して､要件に応じて調整することを推奨しています｡弊社の場合はデフォルトはNamespace単位､高可用性が求められるワークロードについてはService単位でデプロイすることで可用性を担保しています｡

結果

チーム毎の開発環境構築については Istio の Virtual Service を利用したヘッダールーティングで実現できました｡また､Progressive Delivery については後述させていただいていますが､Argo Rollouts との組み合わせで実現できました｡

来年の3月でProduction運用開始後1年が経過するため､別途テックブログで運用事例について共有させていただければと思います｡

モジュラーモノリスのマイクロサービス起動モード

背景

アソビューではアプリケーションのアーキテクチャにモジュラーモノリスを導入しています｡ 同じコードベースのアプリケーションを､ドメイン毎にワークロードを分離して運用しています｡ そんな中モジュラーモノリスのコードベースが大きくなってきており､実行時に必要なコンピューティングリソースも比例して増加していました｡ 例えばJVMのMetaspaceのOOMが発生するようになり拡張を続けている状況でした｡

en-ambi.com

環境変数による読み込みモジュールの制限

アプリケーション起動時に読み込むモジュールを指定可能にすることで､各ドメイン毎に分離されたワークロードが必要最低限のリソースで起動できるようにしました｡ 実行環境の環境変数を参照して､SpringBootのConditionalOnExpressionアノテーションによってロード対象のBeanを制御することで実現しています｡

結果

NonHeap領域をアベレージで約100MB弱削減することができました｡

NonHeapの削減結果

EKS on Fargate の廃止

背景

きっかけは Istio導入時の課題解決でした｡

Ambient Mesh モードが DaemonSet を前提とした設計になっているため､Fargateで稼働しているワークロードを ServiceMesh に入れることができないことがわかりました｡ Fargate の Pros/Cons には以下がありました｡

Pros

  • ノイジーネイバーを気にすることなくワークロードを実行できる
  • SPOTインスタンスの中断を気にすることなく実行時間が長いバッチ処理を実行できる
  • EKSアップデート時に楽をできる

Cons

  • DaemonSetを用いた仕組みが利用できず､FargateではSidecarを利用した個別最適化が必要
  • ログのマルチライン対応ができない
  • Fargateの起動に時間がかかる

方針

下記2つによって EKS on Fargate を廃止して､オンデマンドノードに移行しました｡

1. ノード : ポッド = 1 : 1 によるノイジーネイバーの回避

アソビューでは最高レベルの高可用性を求められるワークロードがありますが､それらをEKS on Fargateから移行する場合にも同様にノイジーネイバーを回避する必要がありました｡ノードにtaints､ポッドにpodAntiAffinity/tolerationsを定義して､ノードにはワークロードの Pod + DaemonSet のみスケジューリングされるようにしています｡

これにより DaemonSet の恩恵を受けつつ､ワークロードの可用性を担保できるようになっています｡

2. バッチ用のオンデマンドノードの運用

ある程度実行時間が長いバッチについて､FargateからSPOTインスタンスへの移行はバッチの信頼性担保の観点でNGでした｡そのためバッチ実行用のオンデマンドノードを利用する方針にしました｡リソースサイズ毎に大まかにノードグループを分けており､それらのノード上でバッチを実行するようにしています｡常時起動するノード数については､高頻度に実行されるバッチを基本としてキャパシティプランニングを行い定義しています｡

結果

高可用性を維持しつつ､すべての Workload で DaemonSet による処理の共通化ができました｡特にログのマルチライン対応についてはプロダクトチームにもメリットを提供できました｡

DB権限管理の再設計

背景

アソビューでは RDB として MySQL､PostgreSQL､Spanner を利用していますが､権限管理について下記課題がありました｡

  • 機密情報が格納されたテーブルへのアクセス制限ができていないDBがあることによるリスク
  • 権限管理の仕組みや､権限付与時のフローが統一されていないことによる運用負荷高騰
  • ユーザーによっては編集権限が常時付与された状態で運用時の安全性が低い

下記テックブログで､Spanner にフォーカスした記事を公開しているので､ぜひご覧ください｡

tech.asoview.co.jp

全DBで統一されたIFの提供

この施策で一番注力した点は､1つの WorkflowTemplate から MySQL / PostgreSQL / Spanner すべてに対して権限付与・権限剥奪が可能な仕組みを構成することです。下記のようなアーキテクチャで実現しました｡

  • sensitive_tables : 機密情報を扱うカラム及びテーブルなどの情報を格納するテーブル
  • default_role_bindings : 個人ユーザーとデフォルト権限のマッピングを格納するテーブル

DB権限管理の再設計のアーキテクチャ

結果

9月から運用開始しましたが問題なく運用できています｡また､機密情報閲覧権限以外にデフォルト権限を最小限に再設計したことで､本番環境での作業リスク軽減にもなりました｡

Kustomize → Helmfile移行

背景

下記記事で紹介させていただいたとおりです｡

tech.asoview.co.jp

結果

上記ブログで触れていたメリット以外にも､執筆以降 Helmfile Template 機能を活用してプロダクトチーム毎の開発環境構築時に必要な manifest定義を削減できました｡

  • Before : Staging環境のmanifestをコピーして必要に応じて書き換える
  • After : Staging環境との差分だけを定義する

具体的には Helmfile Template 機能の readFile 関数でStaging環境のmanifestを読み込み､定義されている差分だけ上書きしたmanifestを出力するようにしています｡これによりStaging環境の manifest の更新に各開発環境のmanifestが追いつけなくなる課題も解消できました｡また､各開発環境のmanifestの行数も122行から21行になり80%削減できました｡

Serverless Framework → Lambroll 移行

背景

当時 Serverless Framework v3 を利用していましたが､下記課題がありました｡

  • Node v22(LTS) が動作しない
  • Serverless Framework v3 が 2024年末で公式サポートEOL
  • Serverless Framework v4 から有償化

困ったこと

苦労した点については､下記クラウドワークスさんのブログに記載されている通りでした｡Serverless Framework (CloudFormation) をリバースエンジニアリングしながらTerraform管理に移行する部分が特に大変だったように思います｡

engineer.crowdworks.jp

結果

  • コスト最適化
  • インフラの管理/アプリケーションの管理/Lambda関数のデプロイを分離
  • インフラ管理を社内で利用しているTerraformに統合

下記のような責務分離になっています｡

LambrollとTerraformの責務分離

Progressive Delivery の実装

背景

アソビューではお客様に提供する機能の中で､購入･着券(入場)のような特にミッションクリティカルなユースケースがあります｡これらの機能については障害発生時の影響範囲を局所化するために､リリース時間を制限しています｡これによりリリースサイクルの低下､リリース作業の運用負荷高騰などの課題がありました｡

Istio × Argo Rollouts による Progressive Delivery

Istio × Argo Rollouts の Analysis Template を組み合わせて､Progressive Delivery を実装しています｡

Analysis Template では Datadog の Monitor のステータスを参照するようにしており､リクエスト数が一定以上ある全エンドポイントのエラーレートを監視･分析します｡障害の早期発見､自動ロールバックを可能にすることで、今まで制限されていたリリース時間帯の緩和と、リリースサイクルの高速化を目指しています。

結果

まだ運用開始前であり年内に運用開始を目指して進めています｡運用開始後に別途ブログなどで詳細を共有できればと思います｡

まとめ

現在SREチームは､SRE + インフラ管理 + プラットフォームエンジニアリングの領域について責任を持って活動しています｡ 本記事ではその中から代表的な施策をピックアップして紹介しました。 今後は下記のようなことを進めていきたいと思っています｡

  • monorepo管理ツールの導入によるローカル環境/CI設定の最適化
  • CircleCIからGithubActionsへ移行
  • 非同期処理のリアーキテクチャ

さいごに

現在アソビューでは「生きるに、遊びを。」をミッションに、一緒に働くメンバーを募集しています！
ご興味がありましたら、ぜひお気軽にご応募ください！
www.asoview.co.jp