Clauda.jsでNode.jsマイクロサービスをAWS Lambdaにデプロイする - 作者Gojko Adzic氏とのQ&A

InfoQは先日Gojko Adzic氏と，氏の最新プロジェクトであるClaudia.jsについて話す機会を得た。Claudia.jsは，Node.jsを使用したマイクロサービスアプリケーションのAmazon Web Service (AWS) Lambdaへの展開をアシストするツールだ。Claudia.jsは，ひとつのコマンドでAWS Lambda関数とWeb APIを展開することができる。IAMロールの伝搬待機の自動処理やconsole.logのCloudWatchへの転送設定を行い，AWS Lambda関数の運用，展開，テストに関するバージョニング管理を容易にする。

AWS Lambdaは，イベントに応答するコードの実行と，その基盤となるコンピュータリソースの管理を行なう計算サービスである。Amazon S3バケット内のデータ更新，Amazon DynamoDBテーブルの変更，あるいはAmazon API Gatewayを使用してHTTPリクエストへの応答(いわゆる’サーバレス’アーキテクチャ)など，複数のイベントに対してコードを自動実行することが可能だ。

Neuri Consulting LLPのパートナであるAdzic氏は，AWS Lambdaへのデプロイメントを潜在的に複雑なものにしているのは，それに必要な手順の多さだ，と指摘する。そこで氏は，Lambda関数の生成や更新をもっと簡単にする目的で，Claudia.jsを開発した。Node.jsを使用した‘マイクロサービス’ AWS Lambdaアプリケーションをコマンドひとつでデプロイ可能なことに加えて，Claudia.jsは，console.logのCloudWatchへの転送設定や，Amazon API GatewayのリソースがJavaScript開発者の期待する動作をするような設定など，多くのタスクを自動化してくれる。

InfoQはAdzic氏にClaudia.js開発の動機や目標を聞くとともに，実運用システムの実行手段としてのAWS Lambdaの可能性について議論した。

InfoQ: こんにちはGojko，今日はInfoQに時間を割いてくれてありがとうございます。マイクロサービスのデプロイに関する新プロジェクトのCloudia.jsについて，紹介をお願いします。

Adzic: Claudia.jsは，JavaScriptコードをAWS Lambda内で正しく動作させるために必要な，デプロイワークフローとエラーを起こしやすいタスクを自動化および簡略化します。これにより開発者は，AWSサービス特有の性質に煩わされることなく，本当の問題に集中できるようになります。Claudiaは，JavaScript開発者が期待するすべてのものをセットアップしますから，彼らの慣れ親しんだ方法で使用することができます。Claudiaを使えば，単純なHTTPエンドポイントの開発とデプロイには５分も掛かりません。デモンストレーションがこちらのビデオでチェックできます。

オンデマンドなスケーラビリティ，ゼロ・オペレーションオーバヘッド，ほぼ無償での運用，利用単位価格，といったものを提供するAWS LambdaとAPI Gatewayは，サーバ側コードを実行する手段として非常に魅力的ですが，シンプルな運用については特に，そのセットアップに時間が掛かり過ぎます。さらにランタイムがJavaコード向きであるため，Node.jsの関数を実行するには，正確にドキュメント化されていない数多くの問題に対処しなくてはなりません。

Claudia.jsはこれらをすべて解決します。例えば，JavaScript関数をWeb APIにして接続するには約120行のシェルスクリプトが必要ですが，Claudiaを使えば，たったひとつのコマンドで実行することができます。

InfoQ: Claudiaの全体的な目標は何ですか，また，目標としていないものは何でしょう？Senaca.jsやgo-kit，Spring Cloudなど，マイクロサービスを対象としたツールキットがたくさん登場していますが，Cloudeaはこれらよりもデプロイメントに重点を置いているように思えるのです。

Adzic: クラウド上に占めるマイクロサービスの割合は今，急速に拡大しています。新たなフレームワークやツールもいたるところから現れています。今あなたが名前をあげたものは，ほとんどがフレームワーク，つまり標準的な通信タスクや作業分散，サービスディスカバリなどを手掛けるためのものですが，私たちのユースケースには機能的に過剰でした。GETやPOST要求に反応したり，S3のファイルを処理したり，あるいはAWS SQS/SNS Queueメッセージを操作したりといった，もっと単純なものが欲しかったのです。AWSサービス自体がすでに十分な機能を持っていますから，それを直接使えれば十分だと思っていました。

Herokuからのマイグレーションでは，大きな問題に直面しました。定型的なセットアップが毎回，山のように必要だったのです。これは複雑で，間違いも起こしやすくなります。それと，私たちは，コードの管理方法やプロジェクトの構造，サービスへの接続方法などは変更せずに，AWSを抽象化しておきたいと考えていました。そのためには，Lambda上で確実かつ迅速に動作させられるものが必要だったのです。

Claudiaはまさにそのためのものです。定型処理をすべて受け持ってコード構造を簡素化する一方で，既存のAPIなどをLambdaに移行するためのオーバーヘッドもほとんどありません。クエリ文字列やフォームポスト，リクエストヘッダなどを，JavaScriptで簡単に利用できるようにすべて収集し，JavaScript APIに必要な方法でプロセスをセットアップします。これをどのように利用するかは，自分で決めればいいのです。

InfoQ: Claudiaを使用する場合と，AWS Lambdaの標準的なアプローチでアプリをデプロイする場合とは，どのような違いがあるのでしょう？また，Mitch Garnaat氏が開発している’Kappa’とは，どのような違いがありますか？

Adzic: ClaudiaのAWSデプロイのアプローチは標準的なものです。定型処理を自動化しているだけなのです。不必要なマジックの導入は避けたかったので，標準的なAWS Node.js SDKを全面的に使用しました。AWS APIコールの正確な順番や，有効にしなければならないセキュリティポリシなどを覚える必要をなくして，解決すべき問題に集中できるようにするためです。

Kappaの機能はClaudiaにかなり近いようですが，Pythonを対象とする点が違います。Apexなど，他の言語を対象とするものはいくつかありますが，私が調べた限りでは，JavaScriptを扱うものは見つけられませんでした。汎用的なフレームワークならばもっと多くのランタイムをサポートしますが，言語固有の部分への対処は開発者に任されています。それに，LambdaでJavaScriptを実行させて気が付いたのですが，言語固有の問題というのは実にたくさんあるのです。

ClaudiaはJavaScript/Node.jsでのみ動作しますが，それに特化しています。Node.jsに重点を置いているため，パラメータと結果をJavaScriptで処理しやすいオブジェクトに変換するテンプレートが，自動的にインストールされます。JavaScript開発者が希望する動作が，アウトオブボックスで可能になっているのです。例えばHTTPコード200で通知されるエラーは，Javaでは大きな問題ではありませんが，大部分のJavaScript Promise HTTPライブラリの動作を損ないます。そのためClaudisaでは，HTTP 500を返送するAPIゲートウェイを自動的にセットしています。

InfoQ: Claudia.jsを開発しようと思った動機について説明して頂けますか？大規模プロジェクトの一部だったのでしょうか？

Adzic: MindMup 2.0を開発している時，バックエンドコードのHerokuからAWS Lambdaへの移行に着手したのですが，その作業のためにチェックリストやトラブルシューティングのヒントを大量に集めました。それらを自動化して，使いやすいAPIを加えたのがClaudiaの原形です。

しばらく経って私たちは，すべてのサーバコードをLambdaに移行する計画を立てました。MindMup 2.0は基本的に単一のHTMLファイルで，バックエンドAPIによる動的機能を備えたCDNを使って実装されています。この構成によって，幅広いユーザを安価にサポートすることが可能なのです。

InfoQ: AWS Lambdaはすでに実用の域に達していると思いますか？もしそうなら，代表的なユースケースはどのようなものになるでしょう？

Adzic: 私たちにとっては，これまでのところ問題なく動作しています。プロジェクト毎に違った制約がありますから，“実用レベルに達している”というのは，その状況次第ですね。私の意見としては，１秒ないし２秒のレイテンシが問題でなく，スループットや並列実行，オンデマンドのスケーリングが重要なのであれば，比較的独立性の高いサーバサイド処理に対する優れた代替手段だと思います。そのような例としては，ファイル変換やユーザのアップロード処理，通知の送信，タスクスケジュール，認証，検証などがあります。

Lambdaを使用する大きなメリットは，管理不要(zero admin)であること，自動拡張，従量制価格，などです。すでに多くの管理作業を必要としているコードでは，あまり大きな違いは得られないかも知れませんし，マイクロ秒単位のレイテンシが必要ならば，Lambda自体が適切な選択肢ではないでしょう。

InfoQ: プロジェクトとして，支援を募集していますか？もしそうなら，コントリビューションする最もよい方法は何でしょう？

Adzic: もちろん。Claudiaはオープンソースですから。クラウド上のコード運用への移行を検討している開発者は，きっとたくさんいると思います。今のところ予定している作業はすべて消化していますが，新たな参加者があれば，より広いユースケースに対応できるようになります。コードはGithub上にありますから，コントリビューションの一番よい方法はそれをフォークして，プルリクエストを送ることです。リポジトリはhttps://github.com/claudiajs/claudiaにあります。

InfoQ: 今日は話を頂いて，ありがとうございます。他にInfoQの読者に伝えておきたいことはありますか？

Adzic: まとめとして，AWS Lambdaでシンプルなサービスを構築して実行したいのであれば，そして，オーバーヘッドが少なくて始めてでも使いやすいものを探しているのであれば，さらに，Node.jsのランタイムが使用できればよいのであれば，Claudiaは適切な選択肢です。SDKのエクスポート，分散環境やアロケーション，サービスディスカバリの詳細なコントロール，Node.js以外のランタイムの使用などを望むのならば，他のツールを使用した方がよいでしょう。

Claudia.jsに関する詳しい情報は，プロジェクトのGitHubリポジトリで見ることができる。Adzic氏は，ツールの使用方法に関する高レベルの概要を示した‘Claudia.js Introduction’という３分間のビデオも制作している。