OracleのサーバレスプラットフォームFnにPrometheusサポートとKubernetes用Helm Chart Installerが加わる

米国オースチンで先日開催されたKubeCon NAカンファレンスで、InfoQは、Oracle Container Groupの副社長であるBob Quillin氏と席を共にして、Oracleのファンクション・アズ・ア・サービス(FaaS)である“サーバレス”Fn Projectにつて話す機会を得た。Fnは2017年10月のローンチ以来、急速な進化を見せている。プロジェクトに新たに加えられたものとしては、Prometheusモニタシステムのサポート、Fn Flow高可用性クラスタの実装、新たなハイブリッドアーキテクチャ、オープンソースのHelm Chart Fn Installerなどがある。

Quillin氏との会話は、Fnがオープンソースで、“どこでも実行可能なイベント駆動のFaaSコンピューティングプラットフォーム”である、という話から始まった(InfoQでは昨年、サンフランシスコのJavaOneで発表されたFnのローンチをお伝えしている)。氏は、Kubernetesのような“オープンプラットフォーム上でのオープンツールの開発”が、“クラウドネイティブ”なアプローチを検討中の組織による採用を増やす上で、最も有効な手段だ、ということを強調した。

Fn Serverに最近追加されたPrometheusメトリックのサポートは、呼び出し統計やパフォーマンスデータ、リソース消費などをPrometheus監視システムと時系列データベースに送信できるようにするものだ。Fnでは現在、関数カウント(関数の呼び出し/成功/失敗回数)、オペレーション継続時間(関数実行などの有意な操作を実施するために要した時間)、Dockerメトリック(Fnが関数をDockerコンテナ内で実行する場合のCPUやメモリ使用量など、コンテナのさまざまな統計数)を提供している。メトリックデータは、一連のGrafanaダッシュボードを使うことで可視化することができる。このダッシュボードは即時に利用可能である。

Quillin氏は、Fnのようなフレームワークによって“DevOpsが最終的に実現される”ことを論じた上で、オペレーションの一部(Dockerイメージへのコードのパッキングなど)を抽象化し、中核的な“観測可能性”ツールを公開することによって、ビジネス価値の提供において開発者がより効率的になることを示唆した。

Fn Flowを使用すれば、少ない計算リソースの消費のみで“長時間動作する、信頼性の高い、スケーラブルな機能”の作成とオーケストレーションが可能になる。Fn Flowでは、すべてのワークフローをたったひとつの言語 -- 現時点ではJavaのみのサポートだが、他言語の初期プロトタイプが存在する -- で定義できると同時に、Java 8のCompletableFuture APIメソッドのような、慣用的な言語構造の使用も可能である。

最新リリースでは、複数のコンピューティングインスタンスへのクラスタリングがサポートされており、プラットフォームを高い可用性で運用することができる。活況を呈している次世代のビジネスプロセスモデリングおよびオーケストレーションツールの市場セグメントにおいて、Fn FlowがRockScriptやApache NiFi、AWS Step Functionsなどと競合関係にあることは注目に値する。

Fnをエンタープライズカスタマ環境に統合していく中で、Oracleのチームは、一部のインストレーションにおいて、さまざまな理由から、インフラストラクチャを実行する顧客の既存コードをAPIインフラストラクチャから分離する要件があることを見出した -- 例えば、あるユーザは、サーバレスプラットフォームを“完全に管理”しながら、ファイアウォールの背後で、コードやデータがネットワークに接続した状態でのコード実行を可能にしたい、という要求を持っていた。これに対してチームは、Fnイシュートラッカ上で動作し、追跡される“Hybrid Architecture”を設計した。

さらにKubeconでは、Fnコアチームが開発したFn Project Helm Chartのリリースも発表された。これによって、Kubernetesクラスタへのプラットフォームの展開が容易になる。プロジェクトの中核的な設計指針は次のようなものだ。“シンプルな展開と管理” -- Fnは複数のコンポーネントで構成され、それぞれにコンフィギュレーション可能な部分がある。これは同時に、運用面での負担として認識される部分でもある。“任意のKubernetesクラスタ(およびクラウドベンダ)のデプロイメントのサポート” -- チャートはクラウドにもオンプレミスにも、さらにはminikueを実行するラップトップ上であっても、ニーズを満たす任意のコンピュータインフラストラクチャにデプロイ可能でなければならない。“オープンソース” -- Fnチームはチャートをコミュニティと共有したいと考えている。

KubeConでの会話の締め括りとして、Quillin氏はCNCF(Cloud Native Computing Foundation)の意義について論じた。CNCFは“クラウドネイティブ”コンピューティングの将来に対するビジョン(と実装)の創造を支援すると同時に、このテクノロジに対する評価基準を提供するものだ、と氏は考えており、Oracleは現在のプラチナメンバシップという立場を引き続き活用する意思を持っている。Fn Projectの今後のロードマップには、CNCFサーバレスワーキンググループとの連携、機能としてCI/CDサポートの重視、IstioやEnvoyなどサービスメッシュテクノロジの役割の検討などが含まれる。

Fnを使ってみたい開発者には、プロジェクトのWebサイトfnproject.ioの参照、Fn GitHubリポジトリにある広範なチュートリアルの調査、プロジェクトのYou Tubeチャネルのコンテント視聴、FnコミュニティSlack経由での質問、といった手段が用意されている。