今日は、AWS SAM を使って Lambda と Lambda を SQS で繋ぐ構成を作ってみよう。
「API Gateway をトリガとする最初の Lambda で UUID を 100件発行し、1件ずつ SQS に投入、後続の Lambda でそれを取り出してログに出力する」という超シンプルなマイクロサービスを構築していく。
今回も、第2話で述べたプロジェクト作成直後の状態をベースに話を進めよう。
つまり、初期状態で API Gateway とそれをトリガとする Lambda 関数までは構築が完了しているものとする。
また、このシリーズをまとめて読みたい人は、Lambda カテゴリのページを参照されたい。
前回はだいぶ駆け足で AWS SAM を使いました。
ただし、DynamoDB とか S3 とか、他のリソースと組み合わせるところまでは到達できませんでした。
なので、今日は DynamoDB のテーブルを作って、Lambda から書き込んでみようと思う。
前回のお話
tercel-tech.hatenablog.com
今回のポイントは、SAM を使って DynamoDB のテーブルを自動作成する点と、それを Lambda と連携させる点である。
リソースの自動作成に関しては CloudFormation と呼ばれるサービスが有名だが、SAM を使うとより簡易にリソース定義を記述できることを示す。
そんなわけで、本日のお品書きがコチラ。 3つの演習を通じて、インフラ構成を含めてコード化する技術 (IaC (Infrastructure as Code)) に触れる。
……はい。
仕事で AWS と関わるようになり早1年が経とうとしているが、未だに使いこなせていないサービスが多い。
AWS Lambda もそのうちのひとつだが、そう遠くない将来、サーバレス案件の比重が増えることが分かっており、なんとかキャッチアップしないといけないと危機感を募らせるようになった。
そこで、Lambda と仲良くなるまでの過程の話を、ここに書き残していきたい。
もともとは 1つの記事に「マネジメントコンソール上で Lambda を作って動かす」→「Cloud9 + AWS SAM CLI で IaC」→「CodeCommit + CodeDeploy + CodePipeline で CI/CD」あたりをまとめて書きたかったが、話があまりにも長くなりすぎたので分割することにした。
今日は、できるだけミニマルなサンプルを通じて、「マネジメントコンソール上で Lambda を作って動かす」レッスンに取り組む話に焦点を絞る。
最近、日々のインプットに対してアウトプットが追いついていない。
ここ数日で一番大きい出来事といえば、仕事で長年コンビを組んできた人間と、万已むを得ぬ事情で別れ別れになったことである。
これまでに築き上げてきた信頼関係などもあり、非常に惜しいことで、この1〜2週間はあまりの喪失感で低空飛行気味だった。
とりあえず近況をまとめてここに書く。
思うところあって電子辞書が欲しくなった。
友人からは、「今の時代、スマホがあるのに何故？」と訝られたが、僕にとって電子辞書はちょっと高価なハンドスピナーくらいの存在感であった。
要するに暇つぶしの手遊び用の玩具が欲しかっただけであり、そこに電子辞書というアイテムを使うこと自体への漠然とした憧れがたまたま重なったのかも知れない。
強いて言えば、僕は多忙になればなるほど言語表現が貧しくなる体質なので、ビジネスメールの品位と格調の底上げを図るためにも脳みそをチートできるツールの助けを借りてみたかった事情もある。
たとえば、なにかの誘いを断る際、「お金がないので……」という凡俗な言い方よりも「手元不如意のおりから……」と文語体で綴る方がお上品であろう。 ときに相手の意に沿わぬ事柄を文章化する際には、波風が立たぬよう「言葉を選んだ感」を演出するのも大人のテクである（何
そんなこんなで、俄然電子辞書が欲しくなった僕は家電量販店に足を運んだ。
ちなみに学生時代は SII 製のモノクロ液晶の電子辞書を愛用していた。 キーボードのタッチ感が快適で非常に気に入っていたが、現在、SII は電子辞書から撤退しており、ほぼ CASIO の EX-Word と SHARP の Brain の2択であった。
さて、もろもろ迷った末、最終的には SHARP 製 Brain の高校生モデルにした。
ネームバリューとデザインでは EX-Word に軍配が上がるのだが、Brain はキーボードをぐるっと裏返せるギミックが気に入った。 机の上に置いて使うだけでなく、手に持ってどこでも使いやすいという、ただそれだけで使い所が一気に増えるのだ。
さらに、Brain はかねてよりユーザビリティの悪さ（特に検索の遅さ）が指摘されていたが、'21年型では EX-Word と遜色ないくらいには改善がなされており、この時点でほぼ Brain に心が固まった。
なぜ、社会人の僕が敢えて高校生向けのモデルを選んだか。
中学・高校生モデルも大学生・社会人向けモデルも筺体そのものに大きな違いはない。
大人向けだからといって特段プレミアムな素材でできているとかそういうわけでもなく、言ってしまえば収録コンテンツとカラーバリエーションがポイントとなってくる。
各モデルの収録コンテンツを比較した結果、個人的には大学生・社会人向けのモデルよりも高校生向けモデルの方に魅力を感じたことが購入の決め手となった。
社会人向けモデルは調べ物に特化している一方で、高校生モデルは教材としての色が強い印象を受けた。 少し前にお世話になった『英文法のトリセツ』3部作も全巻収録されているし、NHK の『リトル・チャロ』も収録されている。
個人的にはこういうキャッチーな教材の方が口に合うなぁと思った次第である。
このほか、書きたいことは色々あるが、ひとまず欲しかった物が手に入って満足である。 暇なときにいじり倒したい。
以上、電子辞書のお話は一旦おしまい。
そういえば少し前に、Kubernetes をがんばる話を書いた。
果たしてあれからどうなったかというと、会社の砂場環境に先輩が構築してくれた Kubernetes クラスタに対して、kubectl コマンドを放つ日々を送っている。
マニフェストファイルをちょこっと書き直して、kubectl apply を叩き、何が起こるか観察することを繰り返しているだけなのだが、そのたびに思い通りに行ったり行かなかったりするので、書籍を参照したり Google 先生に訊いたりしつつ経験値を積み上げている。
時間は限られているものの、会社から金を貰って就業時間中にこういう勉強をさせて貰えるのは、我ながら良い身分だなーと感じる。
さて、この砂場環境がちょっと曲者で、マスタノードもワーカーノードも一緒くたになって 1台のベアメタルサーバ（ 192.168.7.1 ）で動いている。
ワーカーノードには Apache と Jetty をそれぞれベースにした Pod が配置されており、それらが内部的に連携することで一つのシステムを成している。
そして、192.168.7.1 宛の通信は、ポート番号によって Apache と Jetty いずれに疎通させるかを振り分けたい、と言われている。
ところが Kubernetes では、一つの IP アドレスを複数のプロトコルで使用することができないという課題が立ちはだかった。
MetalLB と呼ばれるロードバランサを利用すると IP address sharing が可能になると知った。
Kubernetes does not currently allow multiprotocol LoadBalancer services. This would normally make it impossible to run services like DNS, because they have to listen on both TCP and UDP. To work around this limitation of Kubernetes with MetalLB, create two services (one for TCP, one for UDP), both with the same pod selector. Then, give them the same sharing key and spec.loadBalancerIP to colocate the TCP and UDP serving ports on the same IP address.
Service (type: Loadbalancer) のマニフェストに metallb.universe.tf/allow-shared-ip:"xxx" というアノテーションを付加する（"xxx"は任意の文字列）と、この "xxx" をキーにして複数のロードバランサの EXTERNAL-IP が共通化される。
ただ、設定をいじくり回して kubectl apply を叩いてもなぜか設定が反映されずEXTERNAL-IP が変わらないという事象に遭遇し、ここで数日ハマった。
仕方がないので、一度 kubectl delete で関係しそうなロードバランサを殺して、再度 kubectl apply したところ、無事設定変更が反映された。
習うより慣れろ的な感じで、3歩進んで2歩退がる毎日である。
少し前に、ラズパイが AWS に繋がった話を書いた。
その直後、テクニカルライターの大澤文孝さん (@sour23) から『「TWELITE PAL」ではじめるクラウド電子工作―「クラウド」による処理が「つなぐ」だけでできる! (I・O BOOKS)』という本の存在を教えていただいた。 深謝。
AWS IoT Coreについては、「TWELITE PALではじめるクラウド電子工作」で、ちらっと触れてます。
— 大澤 文孝 (@sour23) April 10, 2021
もし良ければ、本屋でチラ見していただければ……。
（全体のうちの最後の章だけですが）。https://t.co/SDw44y33n0 pic.twitter.com/hypPNQIhpL
「TWELITE PAL」ではじめるクラウド電子工作―「クラウド」による処理が「つなぐ」だけでできる! (I・O BOOKS)
ちなみに、IoT Core を扱う最終章は、本全体のほぼ半分の分量を占めているので、実はかなり力の入ったテーマであることが窺える。
さて、MQTT でデータを収集するところまではとりあえずできたとして、AWS に集めたデータをなんとか加工して有効活用したいと考えるようになった。
そんなわけで最近は AWS Lambda を復習中である。
Lambda もこれはこれで深いテーマで、やり込むと底なし沼だと思っている。
ただ、入り口は軽いし、EventBridge (CloudWatch Events) や DynamoDB や S3 あたりと連携すると、わりかし短時間でかなり強力なモノづくり体験ができるので、機会があればいつかここに書きたい。
このほか色々書き残しておきたいことはあったが、そろそろ長くなってきたので一旦ここで筆を置く。 ではでは。
今週はあまり大した内容を書けない。
前回、ラズパイを買ってモニタに繋いだ。
次にやってみたかったことが、AWS 連携である。
もう少し具体的に言うと、データ収集基盤（っぽいもの）を AWS で構築して、ラズパイからデータを吸い出して遊んだり、あるいはスマホからラズパイを遠隔操作したりということをやってみたかった。
なんとなくこれまでの知識では、AWS の API Gateway と Lambda をうまく活用できまいかと思っていたのだが、実は AWS は IoT 向けにナイスな仕組みを用意してくれていた。
AWS の IoT コンソールにログインすると、「AWS IoT のしくみ」というチュートリアルが見られる。
これは、5分くらいで AWS IoT Core の全体感を俯瞰できて面白い。 チュートリアルというよりツアーに近いかも知れない。
基本的には、MQTT (Message Queuing Telemetry Transport) というプロトコルを利用した Pub/Sub型のアーキテクチャが採用されている。
たとえ、物理デバイスがオフラインであっても、仮想的なシャドーデバイスによって、デバイスの情報にアクセスできる仕組みが整っているという。
初めの一歩として、「AWS IoT クイック接続を試す - AWS IoT Core」という公式チュートリアルを、手を動かして試すことにした。
これがまたびっくりするほど簡単で、だいたい 3ステップくらいで ラズパイから AWS にデータを送りつけることができる。
ぶっちゃけ小学生でもできてしまうのではと思うくらいやさしい。
下図は、実際にラズパイから送られてきた Hello World を購読する様子である。
ラズパイから JSON が次々と AWS に送り付けられているのである。 そして MacBook Pro のブラウザからは、その様子がリアルタイムにモニタリングできる。
さて、こうなってくると集めたデータを捌く裏方の仕組みが作りたくなってくる。
そんなわけで、AWS Lambda をちゃんと勉強したいと思った。
短いけど今日はこれでおしまい。
Copyright (c) 2012 @tercel_s, @iTercel, @pi_cro_s.
