サーバレス開発の入門もどき。README.mdにしたがって作業することで次の知識が身につく。

• Git の簡単な使い方
• AWS Lambda の概要 (何をするか、関連するAWSサービス)
• Serverless Framework を使った簡単な Lambda ファンクションのデプロイ

macOS端末での作業を想定しているが、Bashが使えてGitがインストールされていれば問題ない。

バージョン管理システム。バージョン管理システムは集中型と分散型の2種類に分けられ、Gitは後者にあたる。分散型の特徴は複数人での開発に向いていることである。

ユーザはコードの集まりをリポジトリという単位で管理する。ユーザは全メンバーがアクセスできるところにあるリポジトリ (リモートリポジトリ) を手元の端末にコピーし(クローン)、それを編集した上でリモートリポジトリに適用する (プッシュ)。これを繰り返して開発を進めていく。

GithubはGitのリモートリポジトリの置き場所を提供してくれるサービス(ホスティングサービス)である。公開リポジトリなら無料で作成できるが、非公開リポジトリは有料プランに加入しないと作成できない。超有名。 同様のサービスにはbitbucketもあり、こちらは無料で非公開リポジトリを作成できる。

使い方はサルでもわかるGit入門などを参考にしてもらうとして、ここでは最低限のコマンドを説明する。

macOS端末ならばHomebrew経由でのインストールが簡単である。HomebrewはmacOS用のパッケージ管理ツールで、macOSにデフォルトで用意されていないコマンド群の導入・管理ができる。macOSで開発する人にとってはほぼ必須である。インストール方法は公式ページにある通り、以下をターミナル(bash)に貼り付けて実行するだけで良い。

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

GitのCLIコマンドである git はHomebrewなら次のコマンドを入力することで一発でインストールできる。

brew install git

実際に git コマンドが使えるかどうかを確かめる。次のコマンドはインストールしたGitのバージョンを表示するもので、バージョンが表示されていればインストールは無事完了したことになる。(この例の $ はターミナルのプロンプトという補助表示領域を表しているので実際に入力する必要はない)

$ git --version
git version 2.14.3 (Apple Git-98)

一般にCLIコマンド (アプリケーション) がインストールされていることを確認するときには (コマンド名) --version のようにバージョン確認のオプションを利用することが多い。コマンドによっては -v という短縮系が用意されていたり、逆に -v のみ用意されていることもある。

この Hikosaburou/intro=serverless リポジトリに保存しているコードをローカル端末にコピーする。コマンドは以下の通り。

git clone https://github.com/Hikosaburou/intro_serverless.git ~/intro_serverless

~/intro_serverless には適宜コピー先のディレクトリ名に置き換えてほしい。成功すると、コピー先のディレクトリ内にファイルが追加されるはずである。

$ ls ~/intro_serverless
README.md

このリポジトリにはREADME.mdしか入ってないので上のような表示になる。以降はこのディレクトリ上で作業を行う。

Gitでは単純な時系列によるコードの変更管理はもちろん、ブランチという機能を使った並行作業向けの変更管理もできる。

コードの変更履歴のことをGitではツリーと呼ぶことがあるが、ブランチはその名の通り変更履歴に分岐を作成する。ブランチを作成する(切るともいう)ことでコードの主流から分岐し、並行してコードを編集できる。もちろん、切ったブランチは主流に統合できる(マージすると言う)ため、例えばアプリの商用コードを管理する場合、ブランチを切ってそこで開発を行い、マージすることで商用コードに適用できる。

リモートリポジトリ上にあるブランチはリモートブランチという。手元の端末にあるブランチをローカルブランチという。基本的にローカルブランチはリモートブランチと対応づけられており、リモートブランチの内容とローカルブランチの内容を git コマンドで同期することができる。また、デフォルトではmasterブランチのみが用意されており、これが多くの場合変更管理の源流となる。もちろんブランチは開発者が自由に切れるので、チームによってブランチの切り方のルールが異なっていたりする。

現在のローカルブランチは次のコマンドで確認できる。

$ git branch
* master

* master の意味は「現在 master というローカルブランチが存在し、* マークがついているのでこのブランチ上で作業を行なっている」である。

これからの作業用にブランチを作成する。ブランチは以下の書式で作成できる。

git branch <branch name>

例えば、hogehoge というブランチを作成した後にローカルブランチを確認すると、次のようになる。

$ git branch hogehoge
$ git branch
  hogehoge
* master

作成したブランチを切り替えるには、次の書式でコマンドを実行すれば良い。

git checkout <branch name>

先ほど作成したブランチに切り替える場合の実行例は次の通り。

$ git checkout hogehoge
Switched to branch 'hogehoge'
$ git branch
* hogehoge
  master

git branch で、現在のブランチが切り替わっていることが確認できる。

ブランチの中でコードを作成・変更したら、まずは git add で変更リストに加える。

git add <path to file>

git add したコードをバックアップ可能な点として登録する (コミットする) ために、 git commit を次の書式で実行する。

git commit -m 'commit message'

commit message には通常、変更点を簡潔に記載する (xxを修正、ooを追加、など) 。

この時点ではまだローカルに変更点を登録しただけで、まだリモートには同期されていない。

ローカルブランチでコミットした内容をリモートに同期するために、次の書式で git push を実行する。

git push origin <branch name>

これにより、ローカルブランチと同名のリモートブランチが作成され、ブランチの内容が同期される。ここまでくれば、手元の端末から誤ってファイルを消してしまってもリモートブランチからファイルを復旧することができる。

昨日追加のためにブランチを切り、そのブランチ上で作業し、それをプッシュするところまで説明した。最後にブランチをマージする作業が残っているが、これは最後に説明したい。

Gitの簡単な使い方を知ったところで、本題に入る。ここでは、サーバレス開発の雰囲気を知ることを目標として、AWS Lambda と API Gateway を使った単純な祝日回答APIを作成する。

開発者がサーバを準備することなくプログラムを直接実行させられるサービス一般もしくはその仕組みを用いて作成されたアプリケーション全般のこと。多くの場合は実行時間と利用したメモリサイズに基づく課金となるため、利用方法によっては仮想サーバ型インスタンスを利用するよりも安くアプリケーションを作成できる。

AWSが提供するサーバレスコンピューティングサービスの一つ。AWSの代表的なサービスの一つである。

APIとは Application Programming Interface の略で、あるアプリケーションを別のプログラムで利用するときの窓口のことである。例えばTwitterのAPIをプログラムから使うことでプログラム経由で自動的にツイートをすることができる (つまりbotなんかも作れる)。

API Gateway はそんなAPIをAWSで作成できるサービスである。API Gateway という名前の通り、APIを公開して、そのAPIと実際の処理を紐付ける役割を果たしている。

日本の祝休日を返すAPIを作ってみる。必要な処理は以下の通り。

1. 内閣府のページから祝休日情報をダウンロードしてS3バケットに保存する
2. S3バケットからファイルを開き、祝休日情報をJSON形式に変換する
3. JSON形式のデータから、必要な情報を返す

このページのPDFを参考にLambdaを実装してみる。

触ってみてわかったと思うが、AWS Lambdaのデプロイ作業はただプログラムを書くだけではなく、プログラムを起動させるためのトリガの設定やプログラム内で使うAWSリソースへのアクセス権限の付与など、必要な作業が多く煩雑になりがちである。これを手作業で行うと、デプロイの再現性であったり時間効率が損なわれる恐れがある。

Serverless Framework は上記の問題を解決するためのツールである。これを使うことで、デプロイ時に必要な設定を設定ファイルとして一元管理し、デプロイの再現性を担保することができるようになる。Lambdaをはじめとするサーバレス基盤を利用する際にはこのようなツールを用いて効率的な開発を行う必要がある。

作成したファイルをGithubにプッシュするところまでは前の節で説明した。残る作業は、ブランチのマージである。

ブランチ上で作業をすると、masterブランチとの差分が生まれる。差分を別のブランチに統合することをマージと呼ぶ。この差分の統合作業は通常2人以上で行われる。一人がブランチのマージを要求し、別の一人がその要求を承認する。マージの要求のことをプルリクエスト (Pull Request) と呼ぶ。

プルリクエストはホスティングサービス上で行われる。リモートリポジトリにプッシュを行なった後、Github上でプルリクエストを発行する。 (以降はまだ書けていないので省略)

サーバレス開発について解説するつもりが、消化不良に終わってしまった。この先この文書を改良することはなさそうなので、誰かissueなりプルリクを送ってほしい。