日本IBM社内の技術者コミュニティとして、多彩な活動を展開するTEC-J（Technical Expert Council-Japan）。TEC-J では数多くのワーキンググループが活動しているが、その１つが「Serverlessアーキテクチャの活用研究」である。
2018年に「Serverlessアーキテクチャが適用されているユースケースを検討し、そのメリット・デメリットを取りまとめ、アプリケーションのモダナイゼーションの一部として、どのようにServerless技術を活用すべきかの指針を提示する」という目的で活動を開始した。
2019年は「最新テクノロジーの調査およびコンテナ・プラットフォームとの関連や棲み分け、事例の共有、ユースケースの検討」を主眼に、8名のメンバーで活動を継続している。その研究の成果を紹介しよう。
Serverlessアーキテクチャの概要と特徴
Serverless Computing（以下、Serverless）は、現在ITの世界で最もホットな話題の1つである。Amazon Web Services（以下、AWS）、Google、Microsoft、IBMといった4大クラウドベンダーはServerlessに巨額の投資をしている。
Serverlessとはサーバーがないのではなく、 開発者や運用者がサーバー管理を考慮せずにリソースを使用できることを意味する。
通常アプリケーションを構築する場合、サーバーを実行するために必要なリソースを所有または借用せねばならない。つまりリソースの監視、拡張、容量管理、アップデートといった運用が必須である。しかしServerlessの誕生により、煩わしい運用をクラウドベンダーに任せられるようになった。
Cloud Native Computing Foundation（CNCF）は、Serverlessを「Backend as a Service（以下、BaaS）およびFunction as a Service（以下、FaaS）の双方または一方を意味する言葉」と定義している。
BaaSはアプリケーションのユーザー認証、DB管理といったバックエンドサービスを提供するモデルであり、とくにモバイル向けに特化したBaaSは、MBaaSと呼ばれる。
一方、FaaSとはイベントに応じて柔軟にコードの実行環境を提供するモデルである。ユーザーには関数の実行時間や1秒当たりのトランザクション数といった指標に基づいて使用した分のみ課金される。
Serverlessのなかでも、このFaaSにより提供される環境がマイクロサービスをより効果的に実装できるとして注目を浴びている。
Serverless技術適用
その狙いと考慮点
Serverlessの技術適用にパブリック・クラウドサービスを利用するケースでは、「Zero Server Ops」（CNCF Serverless Whitepaper v1.0）と言われるように、サーバーの定常運用作業から解放されるメリットがあり、前述したようなサーバー自体のリソースの監視、拡張、容量管理、アップデートやバックアップ、セキュリティ対策などは一切不要となる。
また実行された回数や時間に応じた課金となるため、使用用途によってはコストメリットが大きくなると期待される。
Serverless技術適用の考慮点を以下に挙げる。
まずクラウドサービスの使用が前提となるので、そのクラウドプロバイダーにロックインされることになる。メリットとは逆に、サーバーを含むインフラ部分が隠蔽されているため、利用者がチューニングする余地がほとんどなく、性能や内部の挙動はクラウドプロバイダーの実装努力に依存する。
また従来型の監視ではなく、マイクロサービスを対象としたサービス監視や分散トレーシングを用いて問題解析する必要があり、デバッグが困難になるケースが多い。
すべてがServerlessで実装できるわけではないので、これらのメリットやデメリット、各クラウドプロバイダーでの制約事項を考慮しつつ、代表的なユースケースやサービスの利用実績を考慮しながら適用計画を策定する必要がある。
コンテナ基盤との関連や棲み分け
次に、Serverlessの特色を色濃く反映するFaaSに焦点を当て、FaaSがクラウドネイティブなアプリケーションの稼働プラットフォームとしてどのようにユニークであるかを、他の代表的なプラットフォームと比較することで紹介したい。
クラウドネイティブなアプリケーション稼働のプラットフォームとしては、FaaSを含め、物理環境からの抽象度が異なる3つのプラットフォームが挙げられる。
その3つとはまずFaaS、次にKubernetesなどのコンテナ・オーケストレーションに代表されるCaaS（Container as a Service）、そしてアプリケーション稼働プラットフォームを提供するPaaS（Platform as a Service）である。これらの特徴、利点・欠点をまとめたのが図表1である。
FaaS利用を検討する際には、これら3種のプラットフォームが備える利点・欠点を認識したうえで、アプリケーションの特性に応じた適正な利用を検討する必要がある。場合によっては、サブコンポーネントごとに異なるモデルを用いるハイブリッドアプローチも考慮すべきである。
Serverlessアーキテクチャの最新テクノロジー
これまでFaaSは、各ベンダーが独自のサービスを展開してきた経緯から、ベンダー固有の実装が多く、相互運用性に関する課題が多く見られる。
これを背景に、現在のServerless界隈では標準化、相互運用性の向上に関連した動向が顕著である。
FaaS実行のトリガーとなるイベントの標準仕様であるCloudEventsの策定、さらにイベントとFunctionの関連付けと実行制御などの標準化を目的としたServerless WorkFlow、そしてイベントの履歴管理や連鎖などを担うオーケストレーション機能、Functionのロギング、モニタリングなどの可観測性（Observability）関連の仕組みやAPIの標準化などもCNCFへ提案されている。
一方、KubernetesのエコシステムにServerlessワークロードを持ち込むためのコンポーネントセットを提供するKnativeも注目されている（図表2）。
Knative自体がPaaS、FaaSなのではなく、あくまでもKubernetesがPaaS、FaaSとして機能するために必要となるコンポーネントを提供するだけである。
しかしKubernetes上での実行が可能であるという点から、ベンダー不問で、さらにはオンプレミスまでServerless実行環境が展開され得ることを考えると、今後の処理形態の発展に非常に可能性を感じる。
ユースケースの実際
CNCFのホワイトペーパーでは、Serverlessの代表的なユースケースを整理している。そこで紹介されているのが「並列処理」「予測できない大きなスケール変動」「ステートレスな一時処理」「高速開発への対応」の4つである（図表3）。順に説明する。
並列処理
同じロジックを使って、独立した処理を並列して実行するユースケースである。Serverlessの実装として、最も早く成果を上げている。
具体的には、マルチメディア・ファイルの変換処理やDBの変更に伴う通知などである。これらは変更があったことをトリガーにして、並列で同じ変換処理や通知といったアクションを互いに関係せずに実行できる。
予測できない大きなスケール変動
必要となるキャパシティが予測できなくても、サイジングを考慮する必要のないユースケースである。具体的には、IoTデバイスからのセンサデータの処理やストリームデータの処理などが挙げられる。
ピークが読めず、サーバーの事前準備に無駄が多い場合、サーバーの自動スケールで最大値の設定に苦慮する場合などに有用である。
ステートレスな一時処理
セッションなどの状態を表すデータを保持しないロジックのユースケースである。さらに呼び出されたときに、ロジックが読み込まれる応答時間に耐えられる処理である必要がある。
具体的には、ユーザーがある程度の応答時間を待つことができ、都度の問いかけに回答するチャットボットや、スケジュールが決まっているバッチ処理などが挙げられる。このユースケースでは、初期のコールドスタートでロードされたロジックにより、初期以降の応答が早くなる特性を活用する。
高速開発への対応
ビジネス要件の変化が極めて早く、高い開発生産性に対応するユースケースである。具体的には、製品を高速にリリースしてユーザーのニーズを適合させていくアプリケーション、数時間で必要となるアプリケーションのバックエンドのロジックなどが挙げられる。
開発者はバックエンドのスケーリングを気にすることなく、アプリケーションの開発に集中でき、開発生産性を高められる。
Serverlessの活用事例は、これら4つのユースケースに分類できる。いずれもリクエストに応答、スケール、ステートレス、開発への集中といったServerlessの動きやメリットを活かした、または初期の応答が遅れるといった特性を考慮したユースケースである。
Serverlessの役割と価値
ここからは、どのような状況でServerlessのもつ価値が最大化できるか、いくつか例を挙げて見ていきたい。
まずは、マイクロサービスの稼働プラットフォームとしての利用を見てみよう。マイクロサービスでは、各サービスは独立して開発・デプロイされ、それぞれ個別に可用性、拡張性を備える必要がある。
Serverlessでも、各Functionは独立して個別に管理され、アクセスに応じて自動でスケールし、ある部分における障害が他のFunctionの実行に直接影響を与えることはない。
またマイクロサービスはRESTなどの軽量なAPIで通信が行われるが、各FunctionもAPI Gatewayなどと連携し、HTTP着信イベントを処理のトリガーとすることで容易にAPI公開が可能である。
一方で、可観測性やビルド・デプロイ時の自動テストなど、マイクロサービス固有の克服すべき課題はそのままServerlessでの実装にも当てはまるため、Serverlessではどのように対応すべきか、という点も十分に検討したうえで適用する必要がある。
次に、「NoOpsを目指す組織」での適用を挙げる。
NoOpsは、システム運用におけるトイル（手作業で繰り返し行われ、自動化が可能で、長期的に価値をもたらさず、システムがスケールすると作業量も増える、といった特性を備える作業）を自動化によって削減し、究極的には自律的な回復性を備えたシステムを構築することを目標とする一連の作業を指す。
Serverlessを採用することで、サーバーのメンテナンスに関連する運用作業はほぼゼロにできるほか、リクエストに応じてスケールする、などの点でNoOpsが目指す理想像の実現に寄与する。
また、開発のスピードがとくに重視されるスタートアップでの利用も有効である。スタートアップでは金銭的、時間的、人的リソースが限られており、これらを有効に活用するためにもServerlessは有効である。
Serverlessの従量課金モデルは金銭的なリソースに有効であるし、インフラの見積もりや管理からの解放は時間的リソース、人的リソースを節約する。さらにインフラメンテナンスのスキル確保が不要となり、開発に集中できるという点は、人的リソースの有効活用にも寄与する。
このように、Serverlessの登場によって近年のシステム変革は一層加速度を増すと考えられる。
Serverlessの今後
最後に、Serverlessの課題と今後についてまとめる。
まず、開発者人口の多いJavaで実装する場合の課題である。Scale-to-Zeroが望ましいと考えると、JVMの起動時間がネックとなる可能性がある。また、JVM分のメモリ使用量もオーバーヘッドになる。
この課題については、Red Hat社が中心となって開発しているQuarkusとOracle社が中心となって開発しているGraalVMにより、ネイティブ・コードのレベルで起動し、メモリ使用量も少なくなるので、既存のモノリス型JavaアプリケーションのモダナイゼーションにServerlessの活用が期待される。
次に、そもそものServerlessの出発点として、クラウドの利用料を最小化するという目的があり、オンプレミスでは向かないという宿命のもと、利用の広がりがパブリック・クラウドに限定されることも課題である。
そのためには、Knative／Kubernetesを単一システムのレベルでのみ使うのではなく、IBM Cloud Pak Systemのようなハイパー・コンバージド製品の活用も含めて、全社横断のプライベート・クラウド基盤として大規模に用いることで、リソースの利用効率性を高めることも必要となる。
最後に、標準化である。当ワークグループではServerlessに関する標準化の状況を調査したが、結論としてはまだ発展途上にあると言える。ロックインの懸念からServerless採用をあきらめざるを得ない、あるいは、部分的な採用にとどまらざるを得ないと考えて、二の足を踏む状況があると考える。
だが、2019年10月28日付でCNCFからCloudEventsの正式リリース（バージョン1.0）が発表された（Serverless Specification CloudEvents Reaches Version 1.0）。
AWS社が参加していない点が標準化の観点では懸念されるが、イベントに関するメタデータの標準化がなされたことは重要な一歩であろう。CNCFではイベントの次にワークフローの具体的な標準策定の議論が始まっており、また他の分野に関しても提案を受け付けている。
今後標準化が進み、クラウドプロバイダー間の相互運用性の課題が解かれ、エコシステムが醸成されると、Serverlessの適用がさらに促進すると期待される。
IBMはクラウドプロバイダーおよび製品・サービスを提供する立場から、オープン志向でユーザーに価値を提供している。当ワークグループでも引き続き、利用者の立場に立ってServerless技術の進化について注目したいと考えている。
著者
田中 良典氏
日本アイ・ビー・エム株式会社
IBM Services Cloud Center 戦略クラウド推進
シニアITスペシャリスト
2000年、日本IBM入社。ソフトウェア開発研究所で製品テスト、開発業務を経て、2008 年よりデリバリー部門へ。SOAやクラウド・システム構築プロジェクトに従事。2012年、IBMクラウド・マイスターに就任。現在はクラウドに関するソリューション策定および提案支援を担当している。2018年からTEC-J Serverless WGを立ち上げてリーダーとして活動中。
・・・・・
太田 智之氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
クラウド・アプリケーション
シニアITスペシャリスト
1999年、日本アイ・ビー・エム システムズ エンジニアリングに入社。WebSphere製品テクニカルサポート、Webシステムインフラ構築、Webアプリケーション開発などを経て、近年はクラウド、マイクロサービス関連のソリューション開発に従事。剣道三段。
・・・・・
劉 功義氏
日本アイ・ビー・エム株式会社
グローバル・テクノロジー・サービス事業本部
デリバリー＆トランスフォーメーション
エキスパートITアーキテクト
2006年、日本IBM入社。アウトソーシングのユーザーに向けたシステム構築や運用を経て、IBM社内でのクラウドサービス、共用ストレージサービスの立ち上げと運用に関わる。その後に金融業界のユーザーのプライベート・クラウドの立ち上げに参画。情報処理学会、プロジェクトマネジメント学会、経営工学会等各会員。博士（工学）。
・・・・・
佐野 直人氏
日本アイ・ビー・エム株式会社
Cloud Integration Expert Labs
The Open Group
Certified IT Specialist
2002年、日本IBM入社。保険業界のユーザーのアプリケーション開発に携わる。2006年にITコンサルティング部門に異動し、上流工程やワークフロー・コンサルティングに携わる。2009年にソフトウェア・サービス部門に異動し、開発ツール・プロジェクト管理ツールの技術支援を実施。2017年秋からコンテナ管理製品の技術支援を実施。
・・・・・
山﨑 美鈴氏
日本アイ・ビー・エム株式会社
IBM Services Cloud Center
ITスペシャリスト
2010年、日本IBM入社。ストレージ、AIX、WebSphereデリバリーを経て、現在はプリセールスとして主にクラウドの提案支援を担当。グローバルチームとのインターフェースとなり、世界に通用するソリューション策定に従事。
当サイトでは、TEC-Jメンバーによる技術解説・コラムを継続的に掲載していきます。ご期待ください！
TEC-J技術記事：https://www.imagazine.co.jp/tec-j/
［IS magazine No.26（2020年1月）掲載］
