2018年7月13日金曜日

【AWS Lambda】API Gateway の疎通確認

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

最近、AWSをフル活用して社内システムを作ったので、そのノウハウのご紹介を行っています。

ただいま、Lambdaで関数作りを頑張っています。

試しに繋いでみるか

前回「【AWS Lambda】Webリクエストの受付」でひとまずAPI Gatewayをトリガーにくっつけました。

これでもうURLが存在しているのでアクセスしてみましょう。




  • {"message": "Internal server error"}

Internal server error!!

初期状態では動かない!!

テストでは正常

しかしですね、Lambdaのテストでは正常なんですよ。



テストでは正常なのに、実際にアクセスするとエラー。

ここで躓く人って結構多いんじゃないでしょうか?

私も苦労しました。

原因

実はですね、Lambdaのテストは「ラムダ関数だけ」のテストで、API Gatewayは関係無いんですよ。

つまり、上記の状況は

  • ラムダ関数は正常である。
  • API Gatewayでエラーを起こしている。

という状況なのです。

API Gatewayエラーの原因

API Gateway がエラーになる原因。

ログとかそういうの一切出ないですから!!

ネット調査で特定しました。



API Gatewayでは、以下の形式でレスポンスを返さなければいけないと書かれています。

{
    "isBase64Encoded": true|false,
    "statusCode": httpStatusCode,
    "headers": { "headerName": "headerValue", ... },
    "body": "..."
}


関数

つまり、API Gatewayを通せるようにLambda関数を書かねばなりませんから。

def lambda_handler(event, context):
    # TODO implement
    return 'Hello from Lambda'

これを

def lambda_handler(event, context):
    # TODO implement
    return {
        "isBase64Encoded": False,
        "statusCode": 200,
        "headers": {},
        "body": "Hello from Lambda"
    }

こうする!!

結果

無事に表示されました。



これ、知らなけれ本当に意味分からないので、ここで躓かないよう注意して下さい。

続く

引き続きエAPI Gatewayの掘り下げを進みます。

2018年7月6日金曜日

【AWS Lambda】Webリクエストの受付

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

最近、AWSをフル活用して社内システムを作ったので、そのノウハウのご紹介を行っています。

ただいま、Lambdaで関数作りを頑張っています。

Webからのリクエストを受け付けたい!!

Lambda というのは実に色々な長所を持つ優れたアーキテクトですが、私が一番好きなのは、その可用性の高さです。

処理不可に応じて凄く細かい単位で柔軟にスケールアウトして行ってくれます。

この細かい単位でスケールアウトという性質が最も効果を発揮するのは、やはりWebだと思います。

Webというのは人気が無い時はアクセスゼロなのに、どこかで祭りが発生すると一気に数百万ヒットにまで到達することがあるくらいアクセス数が劇的に増減します。


  • Lambda はアクセス数の増減に最強である。


これが最大の長所だと思います。

と言うわけで、HTTPリクエストのトリガーを司る機能「ApiGateway」を見ていきましょう。



Amazon API Gateway概要

Amazon API Gateway は、正確にはLambdaの一部ではなく、Lambdaと連結するAWSの別サービスです。

公式サイトでは以下のように宣伝されています。


  • どのようなスケールであっても、簡単に API の作成、配布、保守、監視、保護が行えます。
  • バックエンドからのデータ、ビジネスロジック、機能にアクセスする、アプリケーションの玄関として振る舞う API を作成できます。
  • 最大数十万個の同時 API 呼び出しの受け入れと処理に伴うすべてのタスクを取り扱います。


が、この表現はどうにも分かり辛いです。AWSのサイトって何かピンと来ない言い回しをされていることが多いんですよね。


早い話、私はこの機能は「WebAPIのURLを疎結合に管理するサービス」だと理解しています。

例えばですね、WebAPIとして「https://www.genesis.com/user/get」というURLがあったとしますよね。

これ、最近はもうデファクトスタンダードになっているRails系規約で考えますと、このURLに相当する処理は「userクラスのgetメソッド」なんですよ。


  • クラス名+メソッド名 = URL


これが命名規約なんです。

でも悪い言い方をすれば、「クラス名・メソッド名とURLが密結合になっている」とも言えます。

内部の実装として都合の良い命名と、人様に向けて公開するURLのネーミングが同じとは限りません。


  • 本番系はこのURL
  • テスト系はこっちのURL


とか、

  • URLの変更に伴ってクラス名を変えなきゃいけなくなっちゃった。⇒大規模リファクタリング

みたいな要件、状況はあり得ますからね。
まあ、規約に頼らず手動でURLとクラスの紐づけを行うという手もありますが、それはそれでデザインパターンとして汚い。

だ・か・ら、


  • 実装チームは実装チームで、Lambdaの中で都合の良いように作ってください。
  • 公開するURLは別途、Amazon API Gatewayで設定します。


ということが可能な疎結合アーキテクトを実現する。

そこにAmazon API Gatewayの美しさがあると私は感じています。

まあ、APIの規模が小さい場合は「実装名=URL」で十分なので疎結合性の利点を感じられないのですが、いずれにせよAPI Gatewayを使わなければWebからLambdaを呼べないのだから、覚えるしかありません。


Lambda で API Gateway の設定

では、Lamda と API Gateway を繋げる設定をしていきましょう。

トリガー追加

まず、Lambdaのコンソール画面からトリガーで API Gateway を追加します。


トリガー設定

トリガーを追加するとすぐ下に設定項目が出てきます。


それぞれの意味はこちら。

  • API 名:API を一意にする為の名前。URLに含まれる。今回は「ApiGatewayTest」
  • デプロイされるステージ:APIを展開するステージ。URLに含まれる。今回は「prod」
  • セキュリティ:必要に応じて権限を付与。今回は全開放であるオープンで。

これで追加ボタンを押せば完了です。

結果、URLは以下のようになります。

  • https://xxxxx.amazonaws.com/prod/ApiGatewayTest

ステージ

ここで少し分かり辛いのは「ステージ」とは何かということです。

URLにも含まれていますね。
これはAPIのバージョン管理や、本番系とテスト系の切り分けに使うものです。

例えば、同じAPIでも「本番用」「総合テスト用」「結合テスト用」を分けて実行したい時、ステージの設定を分けることで簡単に制御出来るわけです。

  • prod ← productionの意
  • staging
  • test

と設定すれば、

  • https://xxxxx.amazonaws.com/prod/ApiGatewayTest
  • https://xxxxx.amazonaws.com/staging/ApiGatewayTest
  • https://xxxxx.amazonaws.com/test/ApiGatewayTest

となる。

分かり易いでしょ?


ステージが不要な場合

「ステージなんていらないから少しでもURLを短くしたい」と、ステージを省略したいというケースもあると思います。

「prod」なんてのは開発者視点のURLであって、一般ユーザから見れば本番以外に無いわけですから。
出来れば消したい。

しかしながら、これは出来ないんじゃないかと思います。
調査しましたが、出来そうな雰囲気が無い。。。

これはステージ名のネーミングセンスで乗り切るしか無いんじゃないかな……。

  • api

と設定すれば、

  • https://xxxxx.amazonaws.com/api/ApiGatewayTest

となるので、一見するとステージ名が露出しているのようには見えないでしょ?

セコい手ですが。。。

続く

今回はここまで。
API Gatewayはバージョン管理とかの機能もあるみたいなので、掘り下げていきたいと思います。

2018年6月22日金曜日

AWS Lambda で環境変数を使用 暗号化と復号

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

最近、AWSをフル活用して社内システムを作ったので、そのノウハウのご紹介を行っています。

ただいま、Lambdaで関数作りを頑張っています。

環境変数を使用する

Lambda には環境変数をセットする項目があります。




環境変数を使用する用途としては、例えばソースにコミットするわけにはいかないパラメータの取り扱いですね。

WebAPIを使用するためのパスワードとかがそれに当たりますが、ソースや設定ファイルにパスワードを書いてコミットしておくとソースをチェックアウトする開発者全員にバレてしまいますから、環境変数にセットしておいておくことでソースには含めないわけです。

他には、私は「実行環境の場所」を判別するのにも便利です。

「ローカルで動作確認する時はこっち」「Lamda上でテストする時はこっち」「本番実行する時はこっち」と今、自分がどのモードで動いているのかを判別する材料として環境変数をセットしておくわけです。

デプロイ時にパラメータを切り替えると切り替え忘れたりしますが、環境変数にセットしておけばそんなことは心配無用ですからね。

その他、ログレベルを動的に変えるとか、使い方は色々。

サーバレスだからこそ、環境変数を便利に使うのがコツと言えると思います。


環境変数をセットして読み取り

では、実際に環境変数をセットしてみましょう。
セットは簡単。

キーと値をセットして終わり。



読み取る時は、その言語標準の方式で読み取ればOKです。
Pythonだとこうなります。

import os


def lambda_handler(event, context):
    param = os.getenv("test")

    # Tacy
    print(param)


簡単ですね。

暗号化

環境変数は暗号化することも出来ます。
暗号化したパラメータは後で復号することも可能です。

キーの作成と暗号化

まず、IAMのマネージメントコンソールから鍵を作成します。



そしてLambdaのコンソールから鍵をセットすると、何やら「暗号化」という項目が出てきましたね。



暗号化ボタンを押すと、もうどんな値が入っていたかは見えなくなります。



さて、後はこれをどうやって復号するかですが、実は「暗号」ボタンのすぐ右の「コード」というボタンを押すとすぐにサンプルソースが出てくるんですよ。

シークレットスニペットの復号

import boto3
import os

from base64 import b64decode

ENCRYPTED = os.environ['test']
# Decrypt code should run once and variables stored outside of the function
# handler so that these are decrypted once per container
DECRYPTED = boto3.client('kms').decrypt(CiphertextBlob=b64decode(ENCRYPTED))['Plaintext']

def lambda_handler(event, context):
  # TODO handle the event here

親切で助かりますね。

では、動作確認してみましょう。

動作確認ソース

import boto3
import os

from base64 import b64decode


def lambda_handler(event, context):
    ENCRYPTED = os.environ['test']

    # 390c9aa7-75f3-11e8-abe0-656e318945ae
    print(ENCRYPTED)

    DECRYPTED = boto3.client('kms').decrypt(CiphertextBlob=b64decode(ENCRYPTED))['Plaintext']

    # Tacy
    print(DECRYPTED.decode())

無事に出力されました。
特に問題は無さそうですね。

終わりに

案外簡単でした。
ただ、この環境変数って昔は無かったそうです。

2016年くらいにリリースされたみたいですね。

Lambdaはまだまだリアルタイムで進化形のサービスなのかもしれませんね。

2018年6月14日木曜日

【AWS Lambda】Lambda コスト節約論

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

最近、AWSをフル活用して社内システムを作ったので、そのノウハウのご紹介を行っています。

今回は気になるニュースを見たので雑談です。

ダイソーで予算超過危機が発生したらしい

ダイソーでLambdaを使ったら年間数千万円のコスト超過に陥るピンチになったらしいですね。


原因は Amazon DynamoDB だそうな。

Lambda と DynamoDB のコスト面での違い

記事を読むと、リスクの原因はLambdaとDynamoDBではコスト面の思想が違うことがキモであるようですね。

Lambdaは従量課金制

私がLambdaに着目する最大の理由ですが、Lambdaは使った分だけ支払う従量課金制です。

Lambdaではない通常のレンタルサーバの場合、サーバを丸ごと一台を借りて占有してしまうわけですから、使っていてもいなくても占有リソースは一定、従って料金は一定です。
つまり、夜中とか誰も使っていない時間帯でも金はそのまま取られているってことですよ。

想定される処理の最大負荷が8と仮定して、それに備えてサーバには10のリソースを割いているとします。
すると、サーバリソースは以下のように消費されます。

レンタルサーバの場合のリソース無駄使い
レンタルサーバの場合のリソース無駄使い

水色の部分が実際に必要なリソース。
グレーの部分はお金をドブに捨てている部分です。

負荷の最大/最小の差が大きいほど、このグレーゾーンは大きくなります。
「日中しか使わない社内システム」とか「人気ゲームの発売日直後だけ忙しくなる攻略Wiki」とか、かなり勿体ない使い方をしていると思います。

対して、Lambdaの場合はこんな感じ。

Lambdaの場合は無駄遣いが殆ど無い

グレーゾーンが殆どありません。

全く無いとは言いませんが、かなり細かい粒度で節約してくれるわけです。
素晴らしい。

DynamoDBは性能ベース

DynamoDBは「プロビジョニングベース」と言いまして、プロビジョニングとは何なのかはさておき、話の趣旨としては要するにこういうことです。

レンタルサーバの場合のリソース無駄使い
DynamoDBの場合のリソース無駄使い
DynamoDBは従量課金制ではない。

つまり、

  • APサーバであるLambdaは従量課金制かもしれないが、DBサーバであるDynamoDBは従量課金制ではない。
  • ダイソーのレジは「忙しい時間帯」と「暇な時間帯」があって、DynamoDBは暇な時間帯でも忙しい時間帯と同じ料金を取られる。
  • だからDynamoDBがコスト超過に陥る。

なんてこった。

どうすれば良いのか?

ダイソーの場合

クラウドの面白い所であるが欠点でもあるという所だと思いますが、クラウド環境ってこういう従来方式であれば考えなくて良い制約ってものがあるんですよ。

それを克服出来るかどうかがエンジニアの腕の見せ所。

記事を見ると、ダイソーの場合はLambdaを遅延させることでDynamoDBの最大負荷を下げて解決したようです。

リアルタイム性が必要無いのであれば、そのようなキュー方式を採用するのも一つのアイデアですね。

勉強になります。

S3を使ってはどうか?

ダイソーのキュー方式作戦は一つの正解だったと思いますが、要点はこういうことですよね。

  • 出来る限りDynamoDBの負荷を下げなければならない。

核心部分としては、DBサーバの負荷を下げる為のプログラムチューニングなわけですよ。

この記事を見た時は、私は直観で「DBを節約したいなら、ファイルでやればどうか?」と思いましたね。

昔、クラウドではないオンプレミス環境のシステムを作った頃の経験なんですけど、私は大量データ収集配布処理を作ったことがあるんですよ。
あの時は「DBで持つ情報」と「ファイルで持つ情報」を分類して管理していました。

  • データはDBではなくファイルで持つ。

この作戦です。

ファイルサーバに相当するAmazon S3は従量課金制だから、DynamoDBみたいボトルネックにはなりません。

ファイルで持つ情報

ファイルで情報を持つ大前提は「ファイルパスが一意キーである」ことです。

DBの用語で表現をするならば、主キー検索だけでしかアクセスしない情報はファイルで持てば良いのです。

DBで持つ情報

DBで持つ必要のある情報は、SQLですね。
「検索フォームから条件を入れて検索したい」とか「group by したい」みたいなSQLの機能があってこそ実現可能な要件のあるデータはDBで持つしかありません。

まあDynamoDBはNoSQLなのでちょっと違いますが、いずれにせよDynamoDBの中になければ使えない機能が必要なのであれば、DynamoDBに持つしかないです。

ダイソーはきっとこっちだったのでしょうね。

冗長に持つ

これは褒められた手段ではありませんが、状況によっては「殆ど主キー検索で使用するデータだけど、ちょっとだけgroup by したい時もある」みたいなケースもあります。

そういう時は、もう腹をくくって同じデータをファイルとDBの二重で持つのも一つの判断です。
データの不整合の余地を残すという弱点が生まれてしまいますが、チューニングには何かを犠牲にするという判断が必要になる時もあります。

ディスク使用量は問題ではない

私の経験則を一つ。
負荷という面において「ディスク使用量」というのは問題にはならんですよ。

あくまで一般論ですが、システムにおいて「ディスクスペース」ってのは安くて余裕があるものなのです。
だからディスクスペースを無駄遣いする代わりに別の部分を高速化するという手法は常套手段としてよく使います。

Amazonの場合もそうで、ファイルスペースであるS3に巨大データが居座っていることは問題にならんです。

  • 0.023USD/GB

1TB使って月23ドル
プロジェクト全体の予算から考えればゴミみたいなものでしょう?
低アクセス領域におけばもっと安い。

チューニングにおいては「どこがクリティカルなのか?」ということを分かっていなければなりません。

注意点ですが、ネットワーク転送量は別の話です。

大量データをS3に置いておくだけなら易いですが、それを無数のユーザにダウンロードさせるようなことをすると、ネットワーク料金がかさんで破産します。
だからダウンロード用データはAmazonではなく別の定額制の場所に置くとか、CDN(コンテンツデリバリネットワーク)を使うとかいった工夫が必要になります。

まあ、そこまで話が伸びるとキリが無いのでここで終わり。

まとめ

ここまで書いて思うこととしては、

  • クラウドはロジック効率がコストに跳ね返ってくる。

ということですね。

丸ごとドーンとサーバを貰っちゃってるオンプレミスとは条件が違いますから、処理効率を考案するアーキテクトの力量が非常に重要です。

ありとあらゆる創意工夫を総動員して総合的に効率的なシステムを構築しなければなりません。

となると、「実装が出来るだけ」みたいなドカタが背負えるようなものでは到底なくて、実装・DB・ネットワーク・AWS特性など色々な側面を平行して考慮出来るフルスタックエンジニアが求められてくるという……。

全く、IT業界は楽じゃないですね。

2018年6月1日金曜日

【AWS Lambda】関数作成4

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

最近、AWSをフル活用して社内システムを作ったので、そのノウハウのご紹介を行っています。

現在はAWS Lambdaの使い方を紹介中です。

前回からまだまだ続いてLambda関数のコンソール画面を調査中です。

ネットワーク


ネットワークは、関数が置かれるネットワークの場所を指定する項目で、VPCを選択することが出来ます。


「VPCって何だ?」というところが問題ですね。


VPCは「Virtual Private Cloud」の略称です。プライベートクラウドです。

要するに、普通にAWSを使っている時、それはパブリッククラウドなのですよ。
インターネット上に存在しているAWSには世界中のどこからでも自由にアクセスして処理することが出来ます。

プライベートクラウドは、例えば「自社の中からしか接続できない」みたいに特定の場所からしかアクセスしか出来ないようにすることで、自分達専用のクラウド空間を実現するということです。

あくまでも仮想的にプライベート化するだけで、物理的には同じサーバに載っていますのでご注意を。

このVPCの設定は、どのネットワーク上に置くのか、ということを選択する項目です。
「非VPC」は普通のインターネットからアクセス可能という意味です。

デバッグとエラー処理


デバッグとエラー処理は、Lamdaがコケた時の通知です。
以下の二つを選択可能です。

  • SNS:Amazon Simple Notification Service
  • SQL:Amazon Simple Queue Service

SNSはFaceBookとかそういうのではないのでお間違え無く。

Lamdaはコケると再実行されるようですが、リトライが一定回数を超えた場合、上記のどちらかのサービスにメッセージを送ります。
これで保守担当に連絡が行って、障害を検知できるという機能ですね。

アクティブトレースとは、「AWS X-Ray」というサービスを活用してより詳細なログを追いかける機能の模様です。 

同時実行数


これは少し驚きでした。
AWS Lambdaは際限なくスケールアウトしていくものと思っていましたが、実際には同実行数1000という上限が設けられているそうです。

「予約されていないアカウントの同時実行の使用」と「同時実行の予約」という言葉がありますが、これはこういうことです。

まず、対象リージョンの対象アカウント毎に同時実行数は「1000」という閾値があり、Lambda関数を100コ作っても200コ作ってもこの同時実行数を消費して処理します。

何も設定しなければ1000ある椅子を早い者勝ちで取っていくわけですが、関数に依っては「大事だから確実に実行したい処理」とか「激増する可能性があるから限度を設けて締めておきたい」とかいう需要もあるかもしれません。

そのな時は、同時実行の値を100とか入れておきます。

すると、その処理の為に椅子が100コ確保されて、その処理はその100の中だけで行います。
他の処理は残り900を共有して行う。

こういう処理です。

よほどの大量アクセスが見込まれない限りはフリーで良いと思いますが、特別な事情がある時は使うことになりそうです。

監査とコンプライアンス


単なる注意書き。
Lambdaでは、監査やコンプライアンスの為に、その関数に対していつ誰が何をしたという証跡を「CloudTrail」という所に保存しているようです。

これにより「誰か知らんうちに何か変なことしやがった!!」って時に犯人を特定できるわけです。

終わり

これでザッと一通り目を通せました。

色々ありましたが、一つ一つはそんなに難しいわけでもなく、使いやすい良いサービスだと思います。

引き続き関数作りを進めていきます。

2018年5月24日木曜日

【AWS Lambda】関数作成3

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

最近、AWSをフル活用して社内システムを作ったので、そのノウハウのご紹介を行っています。

現在はAWS Lambdaの使い方を紹介中です。

前回からまだまだ続いてLambda関数のコンソール画面を調査中です。

関数コード



関数コードは、Lamda関数を実行した時に叩くロジックの管理です。

リッチエディター形式になっていますが、こんな所で実装する人いるのかしら?
普通はローカルで開発してアップロードでしょ。。。

基本は手元で開発したソースをzipファイル等の形式に圧縮してアップロードすることで展開することになります。
アップロードはコツがいるみたいなので、後日検証。

「ハンドラ」という項目がありますが、これは「実行した時に最初にどのメソッドを叩くの?」ということを設定する所です。
これについても後日検証。

環境変数



環境変数は、その名の通り環境変数。
実行環境に応じてパラメータを変えたい時に使用すると便利なものです。

代表的なものとして、秘密情報でしょうか。

例えば「本番環境用のDB接続用パスワード」をGitHubにブチ混んでいてはマズいわけですよ。

そういう時はパスワードは環境変数から取得することで、ローカルではローカルの設定でDB接続し、本番では本番環境変数でDB接続出来ます。
コミットファイル中にはパスワードが存在しないので安心ということです。

項目「暗号化の設定」は、それを更に推し進めたもののようです。

「Lambdaの画面開いたらパスワード丸見えなんだけど?」というのを避けるため、Lambdaコンソールから見える文字列も暗号化しておいてくれるという物です。

そしてソース中で復元する時は、ちゃんと元の文字列になっています。

当然ですが、パスワードをログ出力していたらブチ怖しなのでご注意を。

タグ

タグは、Lambda関数の目印です。
「メールのフォルダ分け」と似たようなもので、Lambda関数が増えてくると探すのが大変になるから、タグをつけて整理出来るようにしておくというものです。

実行ロール

ロールとは権限を管理する機能です。

つまり「この関数はS3にアクセスして良い」というような実行権限を付与するための項目です。
正しく設定しなければもちろん動きません。

関数が増えてくると、こういう所もキチンと整備し、必要最小限の権限のみを付与することで、システムの保守性が上がるわけです。

基本設定


「基本設定」は寄せ集め項目なので、適当なネーミングにしたのでしょうね。。。

説明

関数についてコメントを書いておくもの。

メモリ

重要項目。

Lambdaではメモリを関数に任意でセットします。
ここで設定しているメモリを2倍にしたら、コストも2倍というシビアな項目です。

従って、Lambda関数はメモリ節約こそが大正義ということを意味します。

最近はサーバの性能が上がってメモリも十分に搭載されており、メモリの使用量なんか全く気にしなくてOKという開発が増えてきました。
しかしLambdaでそれは通用しません。

コスト削減のため、「メモリ節約」「処理速度向上」は極限まで追求しなければならないのです。

最小は128MB、最大は3GB。

タイムアウト

関数が開始から終了までに許容する時間です。
現状だと5分が上限です。

Lambdaは小さい処理を大量実行するモデルなので、一回の実行に何時間もかかるようなバッチは思想と合っていないので使用できません。

そういう時はLambdaを使わないという選択肢もありますが、私はデータの範囲を分けて関数を複数起動するなど、あくまで小さなバッチの集積体という思想に従った方が保守性の高いシステムになると思います。

なお、この画面で設定する値の値は5分ですが、ここで設定する値はLambdaのタイムアウト時間で、HTTPリクエストに対応するAPI Gatewayトリガーの最大時間は90秒だったりします。

なので、

「あれ??? タイムアウト時間を5分に設定しているのに、90秒でエラーになっちまうぞ!?」

ということが起きるんですよ。

これは罠です。

続く

関数のパラメータ解説はもう少し続きます。

2018年5月18日金曜日

【AWS Lambda】関数作成2

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

最近、AWSをフル活用して社内システムを作ったので、そのノウハウのご紹介を行っています。

現在はAWS Lambdaの使い方を紹介中です。

コンソール画面

前回からの続きでコンソール画面を見ていきたいと思います。

画面の上の方から行きます。



一番上に「アクション」とかボタンが並んでいますが、この辺りは作った関数をキックしたりする部分です。
これについては後続の記事で書きますので、次に進みます。

デザイナー

デザイナーは、Lambda関数を頂点に、それ以外のAWSサービスを紐づけるための機能です。

初期状態では以下二つがぶら下がっています。

  • Amazon CloudWatch Logs
  • Amazon DynamoDB


Amazon CloudWatch Logs

Amazon CloudWatch Logsは、Lambdaのログを出力するサービスです。

通常のシステムの場合、ログはログファイルに吐き出してローテーションするものですが、Lambdaのようなサーバレスのサービスの場合、無意識に使えるディスクスペースは基本ありません。
なので「ディスクスペースに吐き出す」みたいな簡単な処理に工夫が必要になってきます。

ディスクスペースの代わりにログを吐き出す先、それがAmazon CloudWatch Logsです。

イメージとしては、恐らくNoSQL型のDBにログを保存しているのだろうと思います。
そしてCloudWatchの画面でそれを参照する、というカラクリです。

CloudWatchの画面イメージはこちら。


CloudWatchにログを出力するための実装方法は後日の記事にします。

Amazon DynamoDB

Amazon DynamoDBは、アマゾン自慢のNoSQLです。

【AWS Lambda】帳票出力API開発 その2~RDBMSを使うな~

で書きましたとおり、Lambdaと通常のRDBMSの組み合わせは基本、無いです。
代わりにNoSQLを使用します。

Lambda最大の制約はココ、NoSQLを使うしか無いう点でしょう。

でも性能的には最強なんです。
最近、私はずっと「既存システムをNoSQLに置き換えることは出来ないか?」ということばかり考えています。

例えば、掲示板とかならイケるんですよ。

5ちゃんねる(旧2ちゃんねる)という掲示板がありますけど、あれってサーバ側にはテキストファイルが置いてあるだけでDBは使ってませんからね。

テキスト出力だけでやっている処理はNoSQLに置き換え可能です。

また、PukiWikiという有名なWikiツールがありますけど、あれもテキスト出力だけで実現しています。

LamdaとDynamoDBで実現するNoSQL・サーバレス型のWiki&掲示板というのは負荷の激烈増減というサービスの性質を考えると相性最強のはず。

何とかして自分で開発出来ないかと考えています。


トリガー

さて、最初からぶら下がっている二つは上記のとおりとして、気になるのは左側の「トリガー」です。

これは「何をキッカケとして、Lambda関数をキックするか?」ということを決定するための機能です。

例えば、


  • API Gateway:HTTPリクエストをトリガーとしてのキック


などですね。

以下のラインナップはあります。


  • API Gateway
  • AWS IoT
  • Alexa Skills Kit
  • Alexa Smart Home
  • CloudWatch Events
  • CloudWatch Logs
  • CodeCommit
  • Cognito Sync Trigger
  • DynamoDB
  • Kinesis
  • S3
  • SNS


すいません。
私が作ったシステムだと「API Gateway」か検証していなくて他は未検証なのですが、断片的に調査した情報だと以下の機能だと理解しています。

AWS IoT

AWS IoTというサービスと連動するもの。
例えば「目覚まし時計を叩いたら起動」とか、そういう用途が可能と思われます。

Alexa Skills Kit・Alexa Smart Home

噂のAI製品「Alexa」と連動するもの。

例えば「Alexa! 会議室は空いているか!?」とか話しかけると起動し、Lamdaの処理を経由して会議室予約システムとかと照合し、最終的には「C会議室が開いています」みたいな返事をするとか、
そういう用途が可能になると予想。

CloudWatch Events・CloudWatch Logs

ログ回り。
例えば「ログの中にFATAL」という文字が出現したらキックし、社員に緊急出勤させるような処理のためのもの。

CodeCommit

AWS CodeCommitというGitHubみたいなサービスがあるそうです。
プッシュ通知とか出せるのでしょう。

Cognito

Cognitoはシングルサインオンを管轄する機能です。
「ユーザがログインしたら起動」とか出来るものと予想。

DynamoDB

DynamoDBは上記のとおりのNoSQL。
テーブルの更新を察知することが出来ます。

RDBMSにも「トリガー」という機能がありますが、あれと似たような機能のようです。

Kinesis

Amazon Kinesis Data Streamsというストリーミング処理と連携。

例えば「動画の15分の所でCMを挟む」とかの用途と予想。

S3

S3はAWSの最初期からある伝統のディスクストレージ。

「特定フォルダにファイルがアップロードされたらキック」

SNS

SNS? FeceBookみたいな? と思ったら違いました

Amazon Simple Notification Serviceという、プッシュ通知を行ってくれるサービスがあるそうで。
プッシュ通知の中身をLambdaを使って構築しているのかな?



以上のとおり、沢山あります。

これらから分かるとおり、LambdaはAWS製品を使う上での基幹部分に位置する超重要サービスだと言えます。

AWSに関わっていくなら、Lambdaへの理解は必要不可欠と言って良いでしょう。


続く

引き続きLambdaの関数設定について調査していきます。