OSSで実現する効率化・コスト削減

OpenFaaS活用によるオンプレミスサーバーレス基盤構築で実現したクラウドコスト削減と運用効率化事例

Tags: OpenFaaS, サーバーレス, オンプレミス, コスト削減, 運用効率化

導入部：クラウドFaaSコスト増大と新しい基盤への模索

近年、多くの企業がクラウドサービスの利用を拡大し、開発・運用効率の向上やコスト削減を図っています。特にサーバーレス関数（FaaS）は、インフラ管理の手間なくコード実行環境を利用できるため、一部のワークロードで積極的に活用が進みました。しかしながら、利用規模が拡大するにつれて、従量課金であるFaaSの利用料が当初の想定を超え、全体のクラウドコストを圧迫し始めるという課題に直面するケースが増えています。また、特定のベンダーに強く依存することへの懸念も無視できませんでした。

本記事では、このような状況に直面したある技術部門が、オープンソースのサーバーレスフレームワークであるOpenFaaSを自社で構築・運用するオンプレミス環境へ導入し、クラウドFaaSからのワークロード移行と新規ワークロードの展開を進めることで、クラウドコストの削減とシステム全体の運用効率化を同時に実現した事例をご紹介します。

導入前の状況：拡大するクラウドFaaS利用と顕在化するコスト課題

本事例の組織では、特定のバッチ処理やイベント駆動型の軽量なタスクにおいて、手軽さと開発スピードを重視し、クラウドプロバイダーが提供するFaaSサービスを利用していました。サービスの利用開始当初は、コストも許容範囲内であり、開発者にとってはインフラを意識せずに開発に集中できるメリットを享受していました。

しかし、サービスの拡大に伴い、FaaSを利用する機能が増加し、実行回数や実行時間が予想以上に増大しました。その結果、数ヶ月でFaaS関連のクラウド利用料が急増し、IT予算における無視できない割合を占めるようになったのです。さらに、利用中のクラウドFaaSサービス固有の機能に依存する部分が増え、他の環境への移行が困難になる、いわゆるベンダーロックインへの懸念も組織内で議論されるようになりました。

運用面では、各FaaSインスタンスの監視やログ収集がクラウドベンダーのツールに依存しており、既存のオンプレミスや他のクラウド上のシステムとの統合監視が煩雑になっていました。加えて、特定のランタイムバージョンへの依存や、セキュリティパッチ適用といった管理タスクも、ベンダーの提供範囲に制約される側面がありました。

導入の意思決定と選定：内製化によるコスト抑制と技術的自律性の追求

クラウドFaaSコストの課題に対し、技術部門では複数の選択肢を検討しました。第一に、既存クラウドFaaSの利用方法を見直し、コスト最適化を図るアプローチです。これにはコードのリファクタリングや実行頻度の調整が含まれますが、根本的な従量課金モデルからの脱却には限界がありました。第二に、より安価な他のクラウドプロバイダーのFaaSへ移行する選択肢も検討されましたが、移行に伴う工数や、再び同様のコスト増加リスクを抱える可能性がありました。

そこで、第三の選択肢として浮上したのが、OSSを活用したサーバーレス基盤の内製化でした。このアプローチは、初期投資や運用負荷が増加する可能性はあるものの、長期的にはコスト構造を安定させ、特定のベンダーへの依存度を下げ、技術的な柔軟性と自律性を高められるという戦略的なメリットが大きいと判断されました。特に、既に組織内でKubernetesの運用ノウハウが蓄積され、共通のコンテナ基盤が整備されつつあったことが、この判断を後押ししました。Kubernetes上にサーバーレス環境を構築することで、既存の運用体制やツールとの連携がスムーズに進むと考えられたのです。

OSSのサーバーレスフレームワークの中からOpenFaaSが選定された主な理由は以下の通りです。

意思決定プロセスでは、まず小規模なPoCを実施し、OpenFaaSの基本的な機能、パフォーマンス、そしてKubernetesとの連携性を評価しました。並行して、クラウドFaaSの利用状況詳細を分析し、内製化した場合の費用対効果（構築・運用コスト vs. クラウド費用削減効果）を試算しました。これらの技術的検証と定量的な試算結果を基に、経営層や関係部署に対し、技術的自律性の向上という戦略的なメリットと、具体的なコスト削減効果を説明し、導入の承認を得ました。運用負荷増大への懸念に対しては、既存Kubernetesチームとの連携強化や、必要に応じた外部サポートの活用計画を提示することで対応しました。

具体的な導入・活用：既存基盤への統合とワークロードの移行

OpenFaaSの導入は、既存のオンプレミスKubernetesクラスター上で行われました。OpenFaaSのControl Plane（GatewayやControllerなど）をデプロイし、Kubernetesの標準的な仕組み（Deployment, Service, Ingressなど）と連携させました。

具体的なワークロードの移行にあたっては、既存のクラウドFaaSで動作していた関数を、OpenFaaSのサポートするランタイム（Node.js, Python, Goなど）に合わせてコードを一部修正し、Dockerイメージとしてビルドしました。これらのイメージは組織内で利用しているコンテナレジストリに格納されました。

ユーザーからのリクエストやイベントに応じて関数を実行する仕組みは、以下のようになりました。

  1. 外部からのHTTPリクエストや内部イベント（例：メッセージキューからのメッセージ）が、ロードバランサーを経由してKubernetesクラスター内のAPI Gateway（既存、または別途導入）に到達。
  2. API GatewayがリクエストをOpenFaaS Gatewayにルーティング。
  3. OpenFaaS Gatewayが、リクエストされた関数に対応するFunction Podが起動しているかを確認し、必要に応じてKubernetesにPodの起動を指示。
  4. 起動したFunction Pod内で関数が実行され、結果がOpenFaaS Gatewayを経由してクライアントに返却される。

新規開発されるサーバーレス機能については、当初からOpenFaaSをターゲットとして開発が進められました。開発者はOpenFaaS CLIを使用して、関数の作成、ビルド、デプロイを効率的に行いました。CI/CDパイプラインも整備し、コード変更が自動的にテスト、ビルド、コンテナイメージ化され、ステージング環境を経て本番環境にデプロイされるフローを確立しました。技術的な詳細、例えば各関数のDockerfileの内容やKubernetesのマニフェストについては、本記事では深入りせず、その背後にある運用効率化やコスト削減の判断に焦点を当てます。

導入によって得られた成果：定量・定性両面での効果

OpenFaaS導入による最も顕著な成果は、やはりコスト削減でした。PoC時の試算通り、対象ワークロードをクラウドFaaSからOpenFaaS基盤へ移行したことにより、年間〇〇百万円に及んでいたクラウドFaaS関連費用を、初年度から△△%削減することができました。これは、オンプレミス基盤上でリソースをより効率的に利用できること、そして従量課金ではなく固定費＋利用量に応じたスケール費用の組み合わせになったことによるものです。運用基盤全体の電気代やネットワーク費用は考慮する必要がありましたが、既存のKubernetes基盤のリソースを有効活用したため、追加コストは抑えられました。二年目以降は初期投資が償却され、さらに削減効果が高まる見込みです。

運用効率化の面でも効果が見られました。既存のKubernetes監視・ログ収集基盤（Prometheus, Grafana, Elasticsearch/Fluentd）にOpenFaaSおよびFunction Podのメトリクスやログを統合できたため、サーバーレス部分だけが孤立することなく、システム全体を統一的に監視できるようになりました。これにより、障害検知から原因特定までの時間が短縮され、MTTR（平均修復時間）の改善に寄与しました。また、CI/CDパイプラインにOpenFaaS CLIを組み込んだことで、サーバーレス機能の開発からデプロイまでのリードタイムが短縮され、新しいビジネス要求への対応速度が向上しました。

定性的な成果としては、技術部門の自律性が高まったことが挙げられます。特定のクラウドベンダーの提供する機能セットに縛られることなく、必要に応じて独自のランタイムを開発したり、Kubernetesエコシステムの豊富なツール（Service Mesh, Policy Engineなど）と連携させたりすることが可能になりました。また、新しいOSS技術であるOpenFaaSの導入・運用を通じて、エンジニアのスキルセットが広がり、クラウドネイティブ技術への理解が深まったことも、組織全体の技術力向上に貢献しています。ベンダーロックインへの懸念が解消されたことも、長期的な技術戦略を立てる上で重要な要素となりました。

直面した課題と克服：技術的、組織的な壁を乗り越える

OpenFaaSの導入と運用は順調に進んだわけではありません。いくつかの技術的、組織的な課題に直面しました。

技術的な課題としては、まずKubernetes上でサーバーレスを運用するためのより深いノウハウが必要となった点です。Kubernetesのトラブルシューティングに加え、OpenFaaS特有のコンポーネント（Gateway, Controller）やFunction Podのライフサイクル管理に関する知識が求められました。これについては、OpenFaaSの公式ドキュメントやGitHubリポジトリ、コミュニティSlackなどを活用し、積極的に情報収集と試行錯誤を行いました。社内での勉強会やワークショップを繰り返し開催し、チーム全体のスキルアップを図りました。

次に、サーバーレス関数における状態管理の問題です。ステートレスな関数が基本ですが、一部の処理で状態を維持する必要があり、外部のデータベースやキャッシュサービスとの連携設計が課題となりました。これについては、既存のRedisやPostgreSQLといったデータストアを活用し、関数からはAPI経由でアクセスするアーキテクチャを採用することで解決しました。

また、コールドスタート問題、すなわちリクエストがない間にPodがスケールインし、次のリクエスト時にPod起動による遅延が発生する課題にも直面しました。頻繁に利用される関数には、Minimal Replicasを設定して常に一定数のPodを維持したり、定期的にダミーリクエストを送信したりすることで、コールドスタートの発生を抑制する対策を講じました。

組織的な課題としては、開発者に対して新しいデプロイ・運用モデル（OpenFaaSの関数としての開発）を浸透させる点がありました。これについては、既存のコンテナ開発フローとの類似性を強調し、OpenFaaS CLIや整備されたCI/CDパイプラインの使い方を丁寧に説明することで、スムーズな移行を促進しました。また、一部のチームからはオンプレミスでの運用に対する不安の声もありましたが、既存のKubernetes運用チームがサポート体制を強化し、QA体制を充実させることで信頼を得ていきました。セキュリティパッチ適用などの運用タスクについても、自動化ツールを活用し、担当者の負担を軽減する工夫をしました。

まとめと今後の展望：OSS活用による戦略的なコスト・効率改善

本事例は、クラウドサービスの利用が進む中で顕在化するコスト課題に対し、OSSであるOpenFaaSを戦略的に導入し、自社主導でサーバーレス基盤を構築することが有効な解決策となり得ることを示しています。単なるコスト削減に留まらず、技術的な自律性の獲得や運用効率の向上、そして組織の技術力向上といった多角的な成果が得られました。

この事例から得られる教訓は、クラウドサービスの利便性を享受しつつも、特定のベンダーへの過度な依存を避け、戦略的に内製化やマルチクラウド/ハイブリッドクラウドを検討する重要性です。特に、既にKubernetesのような共通基盤が整備されている組織にとっては、OpenFaaSのようなOSSは有力な選択肢となり得ます。重要なのは、技術的なメリットだけでなく、コスト、運用体制、組織文化への影響を含めた総合的な視点で判断を行うことです。

今後の展望としては、OpenFaaS基盤のさらなる安定運用を図るとともに、現在クラウドFaaSに残っている一部のワークロードや、新たにサーバーレス化が検討されるワークロードへの適用範囲を拡大していく計画です。また、OpenFaaSが提供する非同期呼び出しやイベントコネクタといった機能を活用し、システム全体のアーキテクチャをより柔軟で回復力の高いものへと進化させていくことも視野に入れています。

OSSは、適切に活用することで、単にコストを下げるだけでなく、技術革新のスピードを取り込み、組織の競争力を高めるための強力なツールとなります。本事例が、技術部門責任者層の皆様にとって、OSSを活用した効率化・コスト削減戦略を検討する上での一助となれば幸いです。