ゼロからのサーバーレス化: Cloud Functions を使ってシンプルなマイクロサービスを構築する （パート 1）

※この投稿は米国時間 2018 年 10 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。

皆さんの会社では、あちこちに散在するシステムやサイロ化されたデータを使用しなければ従業員が業務をこなせないような状態ですか。そのようなバラバラのシステムをすべて簡単につなぎ合わせられたらいいのにと思いながらも、どうしたらよいかわからずにいるでしょうか。なんと、そうしたさまざまなシステムを簡単に結合できる、便利で作成もメンテナンスも簡単な方法があります。それはサーバーレス マイクロサービスと呼ばれる方法で、JavaScript のコーディングができる方であれば、いくつもあるエンタープライズ ソフトウェア システムを統合できます。

アリスとボブの 2 人は、ブループリント モバイル（スマートフォンの販売と修理を手がける架空の会社）に勤務しています。ある日の昼休み、アリスはボブから午前中の出来事を聞かされます。ある機種のマニュアルを探し出すのに午前中いっぱいかかってしまい、他に何もできなかったと言うのですが、この会社で使用するドキュメントは、チームのドライブ フォルダ、個人のドライブ フォルダ、古いファイル サーバー、メーカーのウェブサイト、とあちこちに散在しているのですから無理もありません。アリスの頭には、どのマニュアルも 1 つのリンクから見つかる、そんな理想的なシステム像がすぐに思い浮かびます。そこでアリスはボブを説得し、どのようなシステムを構築できるか、午後の時間を割いて検討します。

すべてのドキュメントを一覧表示する URL を作成し、技術者が簡単なウェブアプリを使って目的のドキュメントを検索できるようにする、というのがアリスのアイデアです。アリスは席に戻ると、会社のイントラネット デベロッパーであるキャロルにメッセージを送り、自分のアイデアに不備がないか、会社のイントラネットで動作するかどうかの確認を依頼します。キャロルの助けを借りて、アリスとボブは次のようなアーキテクチャの導入を決定します。

3 人は集まってこのアイデアを検討し、handsetdocs という名前のマイクロサービスから JSON 配列を返すことにします。配列の各要素は、1 つの機種に属する 1 つのドキュメントです。ホワイトボードに書き出されたこの JSON のおおまかな構造は次のとおりです。

次に、修理店のウェブアプリをボブが作成することを決定します。このウェブアプリはアリスのマイクロサービスと次のようなやり取りを行います。

アリスはホワイトボードの写真を撮り、席に戻ると、コードエディタを起動し、Cloud Functions を使用してhandsetdocs マイクロサービスを実装します。

これは、サービスの URL がアクセスされたときに実行される最初のコードです。最初の行でオリジン間リソース共有（CORS）をセットアップします（CORS については、後ほど詳しく説明します）。この関数の 2 行目で getHandsetDocs() を呼び出し、レスポンスを呼び出し元に返します（アリスは後で忘れずに IAM セキュリティも調べなければと、メモを取ります。同僚だけが自分のマイクロサービスにアクセスできることを確認しなければなりません）。

最後にアリスは Cloud Functions でのオリジン間リソース共有（CORS）について調べます。CORS は、あるドメインで実行中のアプリケーションから別のドメインのコンテンツへのアクセスを可能にする仕組みです。これを使用することにより、ボブとキャロルが作成するウェブページは、会社の内部ドメインで実行されても、Cloud Functions のデフォルト ホスティング ドメインである cloudfunctions.net で実行中の handsetdocs マイクロサービスに対してリクエストを行うことができます。詳しくは、CORS について説明している MDN のページをご覧ください。

アリスは上記の 3 つの関数すべてを index.js というファイルにまとめ、handsetdocs マイクロサービスをクラウド ファンクションとしてデプロイします。

getHandsetDocs() のコードは特別なものではありませんが、これによって、ボブとキャロルは会議をしてから 1 時間もしないうちに（handsetdocs マイクロサービスを呼び出す）ウェブアプリのテストを開始できます。

ボブはこの便利なマイクロサービスを利用して、修理店ウェブアプリの最初のバージョンを作成します。アプリの HTML を構成するのは 2 つの空のリストです。最初のリストにはすべての機種が表示されます。そのリストのエントリをクリックすると、2 つ目のリストにその機種に関するすべてのドキュメントが表示されます。

それぞれのリストにデータを取り込むために、アプリの Javascript ファイルから handsetdocs マイクロサービスへの呼び出しが行われます。ウェブページが初めて読み込まれたときに、マイクロサービスが呼び出されてドキュメントのリストが取得され、ウェブページの 1 つ目のリストに一意の機種名が一覧表示されます。ユーザーが機種名をクリックすると、その機種に関連付けられているドキュメントが、同じページの 2 つ目のリストに表示されます。

このコードで、実際のビジネスニーズをかなり簡単に解決できます。アリスはこれをバージョン 0.1 とします。これで、技術者は 1 か所の信頼できる場所からドキュメントを取得できます。また、キャロルは自分のイントラネット アプリからこのマイクロサービスを呼び出して、すべての従業員がアクセスできるドキュメント リストを公開できます。アリスとボブがある午後の時間をこうして費やしたおかげで、社員が目的のドキュメント探しに時間を費やして午前中を無駄にするという事態を今後は防げるでしょう。

その後の数日間、ボブはアリスにさまざまな機種のドキュメントのリストを送り続けます。新しいドキュメントの情報が送られてくるたびに、アリスは getHandsetDocs() 関数に行を追加し、新しいバージョンをデプロイします。このように迅速に更新していくことで、誰かが別の役立つドキュメント見つけるたびに参照リストの情報を増やすことができます。ブループリント モバイルが販売するスマートフォンの機種は少ないため、こうした運用でもボブとアリスの負荷が過剰になることはありません。しかし、システムに取り込むドキュメントの数が急増したらどうなるでしょうか。

こちらをクリックしてパート 2 をご覧ください。パート 2 では、アリスとボブが Google スプレッドシートを使って、他の部署でもこのシステムを使えるようにします。