Oracle Innovation Summit Tokyo 2018レポート（AD）

サーバレスとは何か――OSS「Fn Project」ベースのオープンなサーバレス「Oracle Functions」でできること

2018/08/31 06:00

通知

　7月27日、Oracle Innovation Summit Tokyo 2018において、オラクルが提供するサーバレス技術に関するセッション「Fn Project: 今最も注目すべき「サーバレス」クラウドアプリケーション開発基盤」が設けられた。スピーカーは同社のクラウドプラットフォーム製品管理ディレクターフィリップ・キム氏。オラクルがいうサーバレスとは何か。特徴、コンテナやマイクロサービスとの違い、共通点、そして実際の使い方の解説。サンプルのサーバレスコードの開発デモも行われ、サーバレスのチュートリアルセッションと呼べる内容だった。

通知

UNIXの設計思想とサーバレス

　「Software Tools」という言葉を聞いたことはあるだろうか。

　米ベル研究所のケン・トンプソン氏とデニス・リッチー氏は、1960年代末のMultics（メインフレーム用のタイムシェアリングOS）の反省から「複雑なシステムよりシンプルなシステム」「集中管理より自律分散」「統括より協調」といった設計思想を具現化するため、1970年代初頭にUNIXを世に送り出した。

　このようなポリシーで作られたUNIXは、OSのコマンドやソフトウェア開発にも独特の文化やスタイルを持っている。Software Toolsという考え方もその一つで、ある課題解決のために専用のプログラム（コード）を開発するのではなく、プリミティブなツールをたくさん用意し、それらの組み合わせで複雑な処理を実現するというアプローチのことを指す。

　UNIX（Linuxでもそうだが）のコマンドラインは、標準入出力のリダイレクトやパイプライン処理によって、複数のコマンドを組み合わせて使うことができる。あるファイルをgrepし、結果をsortしてuniqすると、DBMSを使わずとも必要な項目の一覧表が作れる。組み合わせるコマンドは、自分で作ったスクリプトだったりプログラムでもよい。

そのため、プログラムを開発するときは、入出力を固定せずファイルでもキーボードからでも同じように扱える設計にする。特殊なフォーマットやデータ形式に依存するより、テキストデータや標準的なデータ形式を前提とする。必要な処理をすべて盛り込まず、なるべく単機能で実装する。UNIX文化ではこんなソフトウェアを良しとした。

　前置きが長くなったが、「サーバレス」はSoftware Toolsの思想に通じるものがある。ただし、サーバレスでは単機能のコマンドではなく、単機能の関数（ファンクション）として実装する。

コンテナ、マイクロサービス、サーバレスの違い

　コンテナ、マイクロサービス、サーバレスの違いは、コンテナがサーバインフラの仮想化とするなら、マイクロサービスはコンテナを構成するモジュールやパッケージと考えることができる。サーバレスはそれよりさらに小さい単位で、イメージするなら各モジュールが利用する関数群、メソッドに相当するものといえる。

　オラクルのいうサーバレスという概念では、コンテナの中身は「Fn Function」という関数ということになる。サーバレスにおいて1コンテナは1つのメソッドレベルの単機能の関数として機能する（後述）。

　コンテナサーバは、仮想サーバーをさらに抽象化して可搬性を高めることができる。クラウド環境（特にハイブリッド）では、特定サービスやシステムをコンテナ単位で扱うことができるからだ。便利には違いないのだが、コンテナがアプリやサービスの単位だと、機能のモディファイや拡張が面倒にもなる。クラウド上のもう少し細かい機能単位を自由に使えれば、システムの開発が楽になるのではと作られたのがマイクロサービスだとすると、サーバレスはさらに小さい関数やメソッドの単位をコンテナ化して、拡張性や柔軟性を広げるアプローチだといえる。

　ただし、機能の粒度が細かくなると（1コンテナ1機能）、それでブロックプログラミングをするだけでなく、シェルコマンドのようにインタラクティブに使う発想も可能だ。事実、サーバレスのファンクションであるFn Funcitonは、コマンドラインインターフェイス（CLI）を持ち、標準入出力も利用できる。ここがまさに、先に述べたUNIXのSoftware Toolsと類似する点だ。

サーバレスの特徴

　キム氏は、サーバレスの機能や特徴について次のように説明する。

　「サーバレス」はサーバインフラの抽象化の一つであるという。抽象化にはプロビジョニング、スケーリング、パッチ適用なども含まれ、サーバOS、ミドルウェア、ネットワーク部分をまとめただけではない。この点はPaaSとの相違点となる。サーバレスでは代わりに「FaaS（Function as a Service）」という言葉を使う。ここでのFunctionは小さい独立したプログラム。サーバが持つ演算機能の単位ということになる。サービス部分にプロビジョニングやスケーリングといった機能維持のしくみが含まれる（ユーザーはこの部分を気にする必要はない）。またインフラだけでなく、使いたい機能も抽象化されているので、開発が容易だ。

　オラクルでは、Fn Functionを「Oracle Functions」というサービスで提供している。重要な点は、Oracle Functionsはオープンソースプロジェクト「Fn Project」をベースにしていることである。そのため、プラットフォーム、クラウド、オンプレミスなど環境を選ばない（ベンダーロックインなし）。もちろんオラクルらしく、エンタープライズユースを考えてセキュリティ、管理が適用されている。Fn Project自体にもオラクルは深くコミットしている。

　さらにキム氏によれば、サーバレスが支持されるのは、課金がファンクションが呼び出されて実行される時間単位であることも大きいという。Oracle Functionsの場合、100ミリ秒単位での課金となっている。

Fn Functionの使い方とユースケース

　Fn Functionの実体はコンテナなので、利用する場合には何らかのレジストリにコンテナをプッシュする必要がある。呼び出しは「指定のファイルが読み込まれた」といったイベントをトリガーとする。

　実行時課金ということを考慮すると、Fn Functionのユースケースは、イベントベースの処理や、負荷に季節変動がある処理、バッチ系の定期・定時処理、予測不能なピークや突発的イベントの対応、短時間の処理など、「一時的に（時には大量に）発生する処理」になるだろう。

　例えば、画像データをデバイスごとの解像度に加工する処理や、ログデータなどのストリーム処理（ユーザーコメントなどの傾向分析）などだ。バッチ系では、月次の請求処理やポイント計算処理が例示された。モバイルアプリのバックエンドでは、REST APIをトリガーとして、認証処理、DBサービスのエージェントなどにも使える。IoTでは、センサーネットワークの監視、ダッシュボード機能の処理が可能だ。

コーディング作業とデプロイプロセス

　Fn Functionはどのように書くのか。実体はコンテナだが、中身は単機能のコード。入出力はコンテナとして実行環境のリソースが使えるほか、STDIN、STDOUT（標準入出力）が使える。ログはSTDERRに出力される仕様だ。

　コードはJava、Go、Pythonなどで書くことができる。開発キット（FDK）が用意され、デプロイはコマンドラインインターフェイス（CLI）を持っている。開発者は慣れたシェル画面のまま、インタラクティブにコード開発を行い、テスト、デプロイが行える。デプロイでは、REST APIも作られるのでWebからの利用も簡単だ。

　開発者は必要なコードさえ書けば、コンテナのビルド、レジストリへのプッシュ、必要なメタデータの作成などオラクル側用意するFn Serverがやってくれる。

　なお、サーバレスとはいうが、内部ではFn Serverが呼び出しの制御を行っている。GUIも持っているので、デプロイ作業やFunctionの管理、分析をWebベースで行うこともできる。

　では、Fn Function上で動作するプログラムを書く様子を見てみよう。ここでは入力メッセージによって表示を切り替える「Hello World」プログラムをテスト、デプロイするまでの一連の作業を見ていく。

　まず、Go言語で書かれた「Hello」プログラムをfn initコマンドでコンテナ化する。すると、ファンクション本体のgoファイルとyamlファイル、そしてテスト用のJSONファイルが生成された。

プロジェクトディレクトリにサンプルプログラムのgoファイル、yamlファイル、テスト用のJSONファイルが存在することを確認
［画像クリックで拡大表示］

func.go（ソースコード）とyamlファイルの中身
［画像クリックで拡大表示］

　続いてfn deployコマンドで、ファンクションをデプロイする。この時、ファンクションはDockerイメージとしてデプロイされる。それを今度はfn callコマンドで、コマンドラインから呼び出してみる。デモでは、JSON形式のデータ{"message":"Hello World"}が正しく返ってきた。

　次にfn routeコマンドでREST API用のURLを生成し、curlコマンドで呼び出す。実行結果は、先と同じようにシェル画面にJSON形式で{"message":"Hello World"}と表示されるだけだが、確かにプログラム（Fn Function）がその場で実行された

　テストは、fn testコマンドによって行う。先ほどのJSONファイルが起動され、パラメータ処理のパターンが自動テストされた結果が表示された。

fn call、fn routes、curlコマンドによる実行結果と、fn testによる自動テストの結果
［画像クリックで拡大表示］

　Fn Projectは2017年10月のローンチ以来、注目を集めてきた。今後Fn Projectはサーバレスの導入を加速し、完全なサーバレスのプログラミングモデルを生み出しながら、真のマルチクラウドコンピューティング環境で活用されていくだろう。そして、FnのようなフレームワークによりDevOpsも実現され、開発者はより効率的にビジネス価値を提供していけるようになる。ぜひ、Fn ProjectのQuickStartをチェックして、数分間で自身のfunctionを起動し、実際にデプロイしてみてほしい。