クラウド依存からインフラ完全所有へ

概要

クライアント

ウーグウェイ — 日本のテクノロジー企業

課題

50本の本番APIサービスをAWSからセルフマネージドのオンプレミスインフラへ移行

成果

13週間で移行完了。インフラコスト約65%削減。サービス中断ゼロ

置き換えた技術

AWS Lambda、API Gateway、Aurora PostgreSQL、Cognito

導入した技術

Apache OpenWhisk、Keycloak、PostgreSQL（オンプレ）、Express.jsミドルウェア

エンゲージメント形式

アーキテクチャ設計、移行実行、本番切り替え

ウーグウェイは日本に拠点を置くテクノロジー企業で、エンタープライズクライアント向けに社内ツールおよびカスタマー向けデジタルプラットフォームのポートフォリオを構築・運営しています。エンゲージメント時点で、同組織は中規模のエンジニアリングチームを有し、認証フロー、データ取得、ビジネスロジック、サードパーティプラットフォームとの統合をカバーする約50本のAPIサービスを本番で運営していました。スタック全体は創業以来AWS上でホストされており、Lambda関数、API Gateway、Aurora PostgreSQL Serverless、Cognitoを中心に構築された完全マネージドアーキテクチャを使用していました。

2023年末までに、いくつかの圧力が収束していました。AWS費用はチームの使用パターンが正当化する範囲を超えてスケールしていました。マネージドサービスは初期規模では意味のあるプレミアムを持ちますが、組織が自社インフラを運営できるエンジニアリング成熟度を持つと正当化が困難になります。より鮮明な別の懸念はデータ主権でした。日本のデジタルサービスセクターの進化する規制指針によってトリガーされた社内ポリシーレビューで、文書化された本国帰還能力なしにサードパーティのクラウドインフラ上で機密業務データをホストすることは、組織がもはや負担したくないリスクであると特定されました。最後の圧力はより運用上のものでした。AWSによって多くが抽象化されていたため、チームはインフラ動作への可視性が限られていました。何かが予期せず動作したとき、診断の糸口はしばしばマネージドサービスの境界で途絶えました。

コスト、主権、コントロールという3つのことがプロジェクトのマンデートを形成しました。要件はクラウド費用を削減するだけではありませんでした。インフラを完全に所有することでした。

既存アーキテクチャの状況

本番スタックは完全マネージドでした。Lambdaがすべてのコンピュートを処理し、API Gatewayがルーティングとレートリミティングを管理し、Aurora PostgreSQL Serverlessがすべての永続データを処理し、Cognitoが認証とトークン発行を管理していました。外部から見ると、このアーキテクチャは摩擦なく運営されていました。AWSが基盤となる複雑さを完全に抽象化していました。しかしそれはまた、チームがインフラ層を自ら構築、設定、または維持する必要がなかったことも意味していました。

50本の関数が本番稼働していました。サブミリ秒応答を返す軽量なデータ取得エンドポイントから重い処理ジョブまで多岐にわたりました。すべてはAPI Gatewayを介して呼び出され、Cognitoトークンで認証され、Auroraにデータを永続化していました。ReactベースのフロントエンドはAWSのマネージドエッジネットワークを介してルーティングされ、パブリックインターネット経由でこれらのAPIと通信していました。

以前の試みが行き詰まった理由

チームは約18ヶ月前に一度オンプレミス移行を評価していました。その評価は2つの理由で行き詰まりました。まず、APIゲートウェイソフトウェアの選択が論争の的になっていました。Kongが候補筆頭でしたが、オンプレミス環境でKongを立ち上げるには別途データベース、移行スクリプト、サービスとルートの設定、プラグイン管理が必要です。このオーバーヘッドはプロジェクトをフルプロダクトロードマップと並行して取り組むには複雑すぎると感じさせるに十分でした。次に、パブリックドメインのないプライベートLANのSSLの問題が未解決でした。チームはクローズドネットワーク上での証明書配布とブラウザの信頼をどのように処理するかについて確信を持っていませんでした。

これら2つの問題は、2024年にプロジェクトが再スコーピングされた時点でも未解決でした。アーリャ・グローバルが呼ばれたのは、まさにどちらもチームがまだ解決策に到達していなかった対処可能な問題を持っていたからです。

核心となる困難さは移行そのものではなく、単一の関数を移動する前に正しく下す必要があった一連のインフラ決定でした。ゲートウェイまたは認証レイヤーでの誤った選択は、50本すべてのサービスの作り直しを必要としたでしょう。

フェーズ1 — アーキテクチャ設計とスタック選定（2024年1月）

最初の4週間はアーキテクチャ設計とスタック選定に費やされました。このフェーズは意図的に困難な決定を前倒しにし、その後の移行フェーズが自信を持って進められるようにしました。

最初の主要な決定はAPIゲートウェイでした。アーリャ・グローバルは、Lambdaを置き換えるために選定されたサーバーレスランタイムであるApache OpenWhiskが提供する内蔵APIゲートウェイと並行してKongを評価しました。評価では明確なトレードオフが明らかになりました。Kongはより高度な機能（レートリミティング、アナリティクス、プラグインエコシステム）を提供しますが、オンプレミスのコンテキストでの運用オーバーヘッドは大幅に高くなります。管理するパブリック向けトラフィックパターンのないプライベートLAN上の50本の関数に対して、そのオーバーヘッドは正当化されませんでした。OpenWhiskの内蔵ゲートウェイは別個のサービスを排除し、ネイティブアクション統合を活用し、展開の運用表面積を削減しました。KongはAPIのフットプリントが約100本の関数を超えた際に再検討するという文書化された推奨事項とともに脇に置かれました。

2番目の主要な決定はSSLでした。パブリックドメインが関与していないため、公的認証機関のCA署名証明書は適切なツールではありませんでした。アーリャ・グローバルはOpenSSLを使用して自己署名証明書とプライベートキーを生成し、すべてのLANマシンに配布し、クライアントデバイスのWindows信頼済みルート証明書ストアにインストールしました。Node.jsはNODE_EXTRA_CA_CERTS環境変数を介してローカルCAを信頼するように設定されました。これにより、外部認証機関を必要とせずに社内ネットワーク全体で機能するHTTPS設定が実現されました。

3番目のアーキテクチャ上の課題はReactフロントエンドのCORSの問題でした。ブラウザの同一オリジンポリシーがフロントエンドからOpenWhiskへの直接クロスオリジンAPI呼び出しをブロックしていました。セキュリティ上の懸念を生む可能性があるOpenWhisk側でCORSを寛容に設定しようとする代わりに、アーリャ・グローバルはReactアプリケーションと同じオリジンで動作するExpress.jsミドルウェアプロキシを導入しました。プロキシはブラウザリクエストを受け取り（同一オリジン、CORSブロックなし）、サーバー側でKeycloak認証トークンを付加し、同一オリジンポリシーの対象外のサーバー間呼び出しを介してOpenWhiskに転送します。このパターンはブラウザのセキュリティコンテキストをAPIレイヤーからきれいに分離しました。

フェーズ2 — 移行実施（2024年2月）

アーキテクチャが確定した後、2月は移行実施に費やされました。PostgreSQLデータベースがオンプレミスでプロビジョニングされ、AuroraスキーマとデータがまずはAuroraから移行されました。コンピュートが移動される前にデータ層を安定した基盤として確立するためです。KeycloakがCognitoのドロップイン置き換えとして立ち上げられ設定され、トークン発行と検証がExpress.jsミドルウェアを介して接続されました。OpenWhiskランタイムが展開されて設定され、50本のLambda関数がOpenWhiskアクションに移植されました。移植作業は系統的でした。関数ごとに、移行完了とマークされる前にステージング環境で各関数に対して同等性テストが実行されました。

フェーズ3 — テストと切り替え（2024年3月）

3月はエンドツーエンドの統合テスト、パフォーマンス検証、本番切り替えに充てられました。50本のAPI関数それぞれが機能的同等性のために本番データスナップショットに対してテストされました。OpenWhiskランタイムとPostgreSQLインスタンスが現実的なトラフィック下で安定して動作することを確認するため、スタック全体に負荷テストが実施されました。切り替え自体は事前計画されたトラフィック低量ウィンドウ中に実施され、DNSとルーティングの変更が段階的に適用されました。移行期間中にサービス中断は記録されませんでした。

コスト

移行後、月額インフラコストは約65%削減されました。削減の大部分は以前のAWS請求で最も高額な項目であったLambda、API Gateway、Aurora Serverlessのマネージドサービス料金の排除から来ています。残りのオンプレミスコストは、APIトラフィックでスケールしない固定のハードウェア減価償却と電気代が主体です。

パフォーマンス

社内ネットワーク上のAPIレスポンスタイムが大幅に改善されました。以前はAWSのマネージドエッジを経由してパブリックインターネット上でルーティングされていた呼び出しが平均150〜180msでした。プライベートLANでは、同じ呼び出しが現在平均40ms未満になっています。アクションごとに複数の連続したAPI呼び出しを行うユーザーがいる同社の社内ツールワークフローでは、この改善は即座に知覚できるものでした。

データ主権

すべての業務データは現在ウーグウェイが所有・運営するハードウェア上に存在しています。APIプラットフォームにおいていかなるクラウドベンダーへの継続的な依存もありません。同組織は監査機関と規制機関に対して機密データが物理的な構内を離れないことを実証できます。2023年のポリシーレビューでフラグが立てられたコンプライアンスポジションの懸念は完全に解決されました。

運用上の可視性

インフラが現在セルフマネージドになったことで、エンジニアリングチームはネットワークリクエストからデータベースクエリ、関数実行ログまで、すべてのレイヤーの動作に完全な可視性を持っています。以前はAWSマネージドサービスの境界で途絶えていた診断調査が、現在はエンドツーエンドで完全にトレース可能です。

予期しなかった恩恵: フロントエンドパフォーマンス

明示的に計画されていなかった恩恵が、社内ネットワーク上のユーザーのフロントエンドパフォーマンスの改善でした。ReactアプリケーションとAPIレイヤーが同じLANを共有するようになったため、複数のAPI呼び出しを含むページロード時間が社内ユーザーに対して約60〜70%削減されました。これはクラウドルーティングホップを排除した直接的な結果でした。元のビジネスケースでモデル化されていたものではありませんでしたが、移行後にエンドユーザーにとって即座に可視化されました。

“

「2年間、複雑さが高すぎると感じて先延ばしにしていました。アーリャ・グローバルのおかげでスムーズに進み、本番サービスを1つも中断することなくスタック全体が移行できました。」

“

「以前私たちを阻んでいた2つのこと — APIゲートウェイの選択とプライベートネットワーク上のSSL — は、どちらもきれいな解決策があることがわかりました。自分たちでは到達できていなかっただけです。それらが決まった後、移行の残りは通常のデプロイサイクルのように進みました。」

成功した切り替えに続き、アーリャ・グローバルとウーグウェイはインフラ強化の次フェーズで共同作業を継続しています。現在の作業には、自己署名証明書アプローチを自動発行と更新で置き換えるためのSmallstep Step CAを使用した内部認証局の実装と、手動デプロイメントステップを削減して本番変更の適切な監査証跡を導入するためのOpenWhisk関数デプロイメント用CI/CDパイプラインの構築が含まれます。

関数のフットプリントが50を超えるにつれて、APIゲートウェイとしてのKongまたはAPISIXの長期的な評価もスコーピング中です。移行はそのような意図的で段階的な進化が現在可能な、クリーンな基盤を提供しました。

動機がコスト、主権、運用上のコントロールのいずれであっても、この移行へのアプローチ方法と同様のモデルが貴社の環境に適用できるかを喜んで共有します。