Zenn
👩🏻‍💻

【2023/09/23】 #ServerlessDay Tokyo 2023 Day-1

2023/09/24に公開
AI
#
イベント
#
サーバーレス
#
オフライン
#
同時通訳
idea

今回のイベント

https://serverless.connpass.com/event/290640/

26F Opening / CoC & 8yrs of Serverless Community(JP)

会場説明とか運営の話。
サーバーレスの実態というかナマの課題とか。

「もっとうまくやりたい
　誰よりもうまくやりたい」

をキーワードに、今日学んで帰りたい事を周囲でシェアします。

所感

ただの事務連絡のはずなのに、面白おかしくなったのはファシリテーターの腕だな、と感じた。
ダブルエクスプレッソを頼んでいたので一杯飲んだが、めちゃくちゃ目が醒める！

26F [同時通訳]KEYNOTE: TBA

同時通訳は頑張ってリアルタイムに翻訳者の方が頑張るパターンだった！
特にIT用語は日本語で説明するのが難しいですよね、
素直にすごいと思いました。
なるべく生の英語スピーチを聞いて理解しようと頑張ってみましたが、同時通訳の方を聞く状態でした。

サーバーレスの変遷

  • サーバーレスとDynamoDBの親和性。
  • マルチテナントが鍵になるよ。
  • HerokuからLambdaへ。

今のサーバーレス

今のサービス（エコシステム）とサーバーレスアーキテクチャ（Lambda）との相性が良い
AWSのシステムの信頼性の高さ。セキュアになっているかどうか。
▶️別勉強会でもそんな話してたな。リビジョンとAZの話。

AWS以外のサーバーレスサービスを評価する

  • UX
    • Auth0
    • Vercel/Netlify
    • PlanetScale
  • マルチテナント
    • Snowflake
      • RedShift
    • Algolia
    • TiDB, Moment
    • more...

操作性は良くてもセキュリティ面はどうか？

サーバーレスのベストプラクティス

  • プラットフォームを学ぶ(AWS)
  • チームの自主性（開発・保守・運用でチームを分けずにチームを統一・横断できるリーダーシップを）
  • sharpen your tools
    • クラウドとローカルのコラボ
    • デプロイツールの選定
    • モニタリング・ロギング（AWS）
  • 自動化
  • パートナーの選定

実験しながら開発するのが大事。

振り返り(Summary)

所感と変えます。
参考資料もじっくり読み込んでなんぼですね。
意識するべき（守るべき）項目が12

26F [同時通訳]KEYNOTE: The future is serverless / 未来はサーバーレスにあり

スピーカーが超楽しそう。
同時通訳のがバリバリいうのでほとんど聞いてない状態で頑張って書き残します。
▶️接触不良っぽい？
強烈なアメリカンジョーク（かなりアレな）が印象的。

サーバーレスの定義

サーバーのマネジメントが不要でスケーラブル
AWS Lambdaの存在が大きい。もちろん、その他のサービスもある。
▶️AWS FargeteとAWS App Runnerあたりに注目（トレンドの話？）

サーバーレスのトレンド

モノりシックなサービスを分散させるという使い方。

  • ハイパーマイクロサービス？
    • Lambdaの中身を見てみると全部コードなので、読めない人には干渉できない。
      • Lambdaをビジネスロジック単位で使い分けたい（レポーティング
  • EDAアプリケーション
    • とは？：イベント駆動アーキテクチャ。Webhookに通知されたら動くやつ？
    • 監視はpush型？
    • 大体のサーバーレスシステムはこれでは？

コンフィグはコードに勝る

サービスのコンフィグからイベントを発火させよう。
Lambda内で別のLambdaを発火させるやり方だとコードで管理するしかない。
管理コストを考えるとコードからイベントのつながりを追いかけるべきではない。
AWS Step Functionでフローを視覚化できるよ。

  • BTLとは
    • ベロシティテンプレートリッジ？
    • （何の話なのか理解できてないので書けない。あとで調べる）

非同期通信を意識しよう。クライアント（ユーザー）は待ってくれない。
API通信時に非同期アクセスしよう。conputeを入れると、マシントラブルが発生した時に機会損失となる。
サーバーレスファーストを採用している企業の例。

サーバーレスのこれから

  1. EDAを受け入れていく：▶️Lambdaの活用例から見よう
  2. コンテナvsサーバーレスの話ではなく、いいとこ取りをしよう。大規模になるとStepFunctionを使ってFargateとサーバーレスにアクセスして早さと安定性を担保する事ができる。
  3. 生成形AI(GenAI)。使う人が圧倒的多数であるため、オーケストレーションの重要性が高まっている。
  4. DX（いわゆるデジタルトランスフォーメーションではなく、デベロッパーエクスペリエンスとして）向上（AWS SAMやCDKを使おう）

IAC(インフラアズコード)

  • SST (Allows debugging function in the cloud)
  • Winglang.io（プログラミング言語：ローカルにWebUIがあるのでいじれそう）GolangのFWとの違いとかも見たい。▶️IACよりコンフィグだよ、という話をしていたがどこ？
  • GetAmpt.com（）

所感

これ通訳はAI翻訳を読み上げている？
こういったところにも技術を入れているのかな、

サーバーレスアーキテクチャはAWSと密接に関わっているというか、AWSがサーバーレスを意識しているのか。
サーバーレスを学ぶなら必然的にAWSを学ぶことになるだろうな、という印象。
（もちろん、サーバーレス＝AWSとは言わないものの、AWSではないサービスは信頼性の観点で評価する事を忘れてはいけない）

デベロッパーエクスペリエンスとはなにか？

これ日本人かそうでない（翻訳いらずで英語が読める）かはありそうな気がする
特にAWSなりAzureなりでもわかるが、結局のところサービスの使い方を理解しているかどうか、種類を知っているかどうかの話だという印象が出てきてしまっている

26F [同時通訳]KEYNOTE: サーバーを超えて： 開発者のために作られたTiDB ServerlessとChat2Query

日本語セッションになりました。
スライドは英語なのでまだ頑張って読める！

マルチテナンシーの事例紹介も兼ねているので前の発表の復習にもなった。

TiDBとは

分散型サーバーレスDB。バズってアクセスが集中してもAWSを使ってうまいことやってるのでスケーラブル！
その上、MySQL互換があるのでアプリケーションエンジニアの追加教育が必要ない。

https://pingcap.co.jp/

事業として考えるとコストが掛かり過ぎてマネタイズは無理。
使わない時は落として、使っている時だけ立ち上げるモデルにするとどうか？
▶️言ってることは分かるけど、それでも無理ゲー感あるけどなぁ。

その他、リソースをうまいことやって何とかやろうとして解決してみて省コスト化しよう。
重たい処理を切り出してマイクロサービス化を検討するとか。

事例

https://ossinsight.io/

https://aju-cil.com/

▶️楽しくなければサーバーレスじゃない

所感

このアーキテクチャはDBだけに限らず、実務でも色々な環境で書いて使えるぞ！

TiDBもタダで使えるならいいけど、料金プランがよく分からないので手が出せないか。
▶️フリーティアあるそうです。見てみます。
とはいえ、使い方も分からないのと、個人向けだとあまりにもオーバースペックすぎる。
仕組みとしては面白いのでDBチューニングを考える段階になって移行計画を考えるのもアリか。
▶️これもOpenAIに聞いてしまおうという思想らしい。AIBot(LLM）あるからクエリも書かせてしまおう。

26F 失敗から学ぶAPIファースト - 正しいデザインからはじめるアーキテクチャ選定、開発ライフサイクル＆コラボレーション

悩んだけど下に移動

11Fa: Refactoring Serverless

タイトルがどっちか分からない

  • オンプレとかをサーバーレスにリファクタする話？
  • 今あるサーバーレスをAWSに載せ替える話？

Twitterに資料上げるよ！
serverlesslandも参照しよう

サーバーレスシステムを実装する時の選択肢

とりあえずLambda使おうと考えるよね。▶️Yes
Lambdaは便利だけど、Lambda以外にも使えるものあるよ！（本題）

  1. リファクタする時はまずテストを書く（成功・失敗双方）
  2. コードなどをリファクタする
  3. 移行する

Lambdaの中でサービスを呼び出したりしている問題を解消したい
▶️Lambdaの結果をAWS CDKに渡してあげればよし

サーバーレスをリファクタするモチベーション

  • マネージドサービス
  • AWSの追加機能
  • アプリ要件
  • ランタイム特性
  • コスト

Step Function

  • ランタイム要素＝Lambdaをなくして
  • 実行時間と煩雑さを減らす
  • 15分制限を突破

Lambdaの便利な点（Step Function,AWS CDKだけで完結できない）もある。
この辺りはコードで比較した方が良いので資料を確認しよう。

Lambdaの粒度を考える

RESTAPIをLambdaで考える（CRUDの実装）

１つのLambdaで処理する方法と、CRUDごとにLambdaを分けてgatewayで制御する方法が分かりやすいか。
つまり、CRUDのLambdaからCRUDごとに関数（Lambda）を分けるか、という話か（資料に別リンクの資料あるよ）

所感

サービスのアーキテクチャを分けてエラーハンドリングをする、という思想は従来の実装でいうところの関数の切り分け・切り出しと同じ感覚の話。
コードベースで話をすると説得しやすいか。この辺りの情報はベストプラクティスを漁るのが良さそう。

たとえばCIでガリガリコードを書いて、実行結果を受け取るコードを書いて云々〜とやるのはしんどいので、サービスを使い分ける運用の方がいいよ。
▶️これGitHub Actionsでやってるアレコレの話に直結しそう。

他シス・他サービス連結をどう評価するか

結局のところ、モノリシック（Lambda）かマイクロサービス（さまざまなサービス連結）かという話に聞こえる。
別セッションで重たい処理を分ければリソースの節約になる、という話があったが、そういった用途ならまだ理解できる。
ベストプラクティスが分からないとリファクタリングの判断も難しそうだ。

11Fb サーバーレスは死なぬ！みんなEDA(Event Driven Architecture)として使ってるでしょ？

サーバーレスとマイクロサービスを同列に語れないのでは？という疑問
Faas（ファンクションアズアサービス）、ED（イベントドリブン）との相性よし
AWSサーバーレスパターンが公開されてる

  • 100%サーバーレスの例。コレオグラフィーパターン？
    • そもそもサーバーレスにする目的ってなんだっけ？

AWSのイベントを組み合わせてなんかやるのは、いわゆるScratch的なアレを想起する
▶️マイクロ化をdisるわけじゃないけど、誰が管理するのか、管理者を採用して育成できるのか？

所感

何言ってるか分からなかったが、他シス連携の繋ぎ込みはイベントで発火するんだからETAって話？
AWSの中でもサーバーレスの考え方については宗教的な信仰があることは理解した。
サーバーレスの研究はまだまだ続きそう。
（できれば中小でも通用するレベルのマイクロアーキテクトかつシンプルであって欲しい）
良くも悪くもLTっぽいね。個人的には評価

11Fa Next.js × AWS App Runner × AWS AppSyncで進めるクライアントファーストのWEB開発

電池限界…
スマホでメモを書いてますが、書く事がほとんどない（私にとってはあまり使わないサービスのコード実装の話であるため）
JSリゾルバーの話はAWS？というところから理解してない。
電池の都合もあるので、断片的に使えそうなのだけ切り取っておきます。

メモ

  • JSリゾルバーの紹介が主か。コードベース
  • Git flowはレガシーだから byAWS Docs
  • 描画回りをReact flowという組織図作るサービス（これを作ってる？）が良き
  • auth0エンタープライズ高いよ

所感

電池がなくなると精神的安定感がなくなってイベントに集中できなくなるという事がわかったので、モバイルブースターは大事。
MacBookを使っているので充電できるように何か考えておきたい。さすがにUPS（無電源装置）は重い上に大きいので持って来れないけど、昔買ったのがあったのは覚えてる。

11Fb サーバーレスで仮想待合室を作ろう！

この会場、充電できるぞ！！！！
今度（明日）来る時に備えて延長コード持ってこよう（MacBookのでかいアダプタが刺さらず1敗）

もう資料も上がっているとのこと、助かる。
▶️資料あげてる場合はQRコードをスライドに貼ったりすると良き。

何はともあれ、高負荷対策

負荷が上がる時＝有名税。

  • 政府サービス（stable: 常に高い）
  • 災害情報（bumpy: 定期的に高い）
  • ※アーティストライブ（spiky: 突発的に高い）

今日の話はオートスケーリングで間に合わない（スケールが追いつかない、）バースト＝欠損ケースを考えたい。
このバーストに対応するためのアプローチを考えると、仮想待機室はサーバーレスとは関係なくシステムとして良さげ
▶️よく考えたら、電話だって通話待ち状態になるよね。

SHIFT North

この場合、NorthとはクライアントでSouthをキューストリーム（配信サーバー）とする。
トラフィックの終端を北側に寄せたい。CDNを挟む方法もある。
実装を考えると

  • 一次受付のトラフィックを仮想待機室に送る。
  • メインアプリケーション（分かりやすく配信環境とする）にAPIゲートウェイを置きアプリに繋ぐ。
  • 同時接続数を絞って順次処理していく

概念としては新しい取り組みではないね。

所感

デモあり。現地組だと体験できましたが、後ほどスライドを見た方は一人では分かりにくいと思うので、複数のブラウザや端末を駆使してやってみましょう

11Fa サーバーレス アーキテクチャを使って、小さく作って大きくする取り組み

ここまで移動しまくっていましたが、ここからはほぼ定位置に。
なるべく難度の低いものかつ概念理解で対処できるものに限定して選択していた結果、のように思ってます。
LLMの話とかも聞きたかったんですが、活用ならまだしも開発の話は個人レベルでやる事ではないという事を理解したので、話を聞いて分かったフリしかできないのが分かったのです。

取り組みと事例

AWSを活用するためにレギュレーションを規定

  • Pythonでサーバーレスを使う
    • サーバーレスフレームワーク
    • pytest

これを起点に、徐々に範囲を広げていくようにする。
ボイラープレートを作って高速なアップデートを実施していく。

オンボーディング課題を解決

これはサーバーレスの話ではなく、ナレッジマネジメントの話か

  • Wiki化
  • ナレッジを研修課題に使用
    • クライアント向けにも応用

「小さく作って大きくする」とは

まずは動くものを作る

具体的には、車を作る方法をどうやってアプローチしていくかで見る。

Good

  1. スケボーを作る（動く）
  2. ハンドルを作る（動く）
  3. フレームを載せる（動く）
  4. 座席を作る（動く）

Bad

  1. 素材を作る
  2. タイヤを作る（動かない）
  3. フロントを作る（動かない）
  4. リアを作る（動かない）
  5. くっつける（動く）

ウォーターフォールじゃなくてアジャイルでやったという話？
AWSアーキテクチャを順次追加して機能追加をするアプローチ。

所感

ごく普通の話をサーバーレスアーキテクチャの例でお話いただいていた印象。
新しい話ではないけど、別の場所で使えた・知っていたノウハウ（＝開発の現場の常識）がこの場所（サーバーレス）でも使えると認識出来たので意義のある内容。

11Fa LLM × Cloud Runでオンライン薬局の既存オペレーションを自動化した話

LINE上で完結する薬局を自社運営。
CroudRunを活用している話。

業務フロー

LLMを使ったのはオンラインの受付業務部分。
疑義照会（処方箋の誤りを修正する）作業が結構な負荷に。
▶️GPT使えばよくね？

  • 処方箋をテキストか
  • LLMで患者情報を取って構造化する
    • 取得はOCR(AI？)
    • 結果はJSONで出力
    • パターンマッチ（正規表現）も考えたが、人によって色々な書き方をしてくるのでLLMで抽出
      • 医師への問い合わせ文もLLMに出力させる
      • 作成した文書をSlackなどに残す

※この辺りの業務は専門性が問われるので、属人的になりやすいようだ
▶️専門家が見ているポイントをルール化するというアプローチか
Few-Shotプロンプティング？

既存オペレーションに追加しやすいのがサーバーレスのメリット。
ソフト面よりハード（運用。Faxで送ってくるとか）に課題がある。

課題

  • 服薬指導（患者への説明）を文字起こし＋音声通話（電話も自動化）
  • メッセージサジェッション＋レビュー
  • LLMを入れると従来システム化できなかった領域にまで入れるようになった。対応幅が広がった。

所感

これだよこれ！聞きたかった講演でした。
社内システム開発というか、社内で運用しているシステムだからこそできるアプローチの話は面白い！
私も事業化を考えている

11Fa 理解して導入するWebフレームワーク 解決すべき課題に着目する

以下、最小限に抑えたい。

  • コールドスタート
  • 関数の依存
  • 実行時間
  • VPC

環境変数を活用する
▶️これは意外。configの話と同じ感覚で解釈すればいい？

Laravelの話

  • AWS統合
  • Eloquert ORM
  • ルーティング
  • 認可
  • API
  • バリデーション

開発速度とセキュリティ、ドキュメントの豊富さなど良いとこが多い

  • Laravel以外
    • Symphony
    • CakePHP

も選択肢としてはあるけど、今あえて選ぶ理由はなさそう

Brefとは

（意訳）PHPerがサーバーレスを実現するためのライブラリ
カスタムランタイムを開発者コミュニティで共有できる。
※LambdaはPHPを用意していない

PHPとLambdaは相性が悪いんだろうか…？
▶️Brefのサポート切れがこわい

モノリスなLambdaとLaravel

  • パッケージサイズ
  • 最小権限の適用
  • （見落とした…）
  • （見落とした…）

社内リソースがPHPとRuby（Webフレームワーク）に強いので、言語に依存してしまう。
サーバーレスもPython -> Goに変えたがメンテナーが増えず。
↓
言語に依存しないサーバーレス設計を考えていく。
▶️チームで運用できるサーバーレスを考える。

エンジニアは技術的な変化を受け入れやすいが、チーム文化やマインドセットの変化は遅い（とはいえ、他業種と比べると変化の余地があるだけマシか）

AWS LambdaとLaravel

PHP（特にバックエンド〜インフラ）の悩みをAWSが解決してくれる
▶️Webフレームワークをサーバーレス化することでマネジメントコストを下げられる可能性がある

問題点（purePHP VS Laravel)

  • デプロイタイム
  • パフォーマンス
  • 学習コスト

モノリス vs マイクロサービス

排他的ではなく、うまく使い分ける
モノリスな機能とマイクロな機能の切り分け。
極端なのはよくなく、モノリスにすると負荷やスペック（リソースへのコスト）面の課題があり、マイクロにすると管理の問題がある。
問題は、どこまでのモノリスの課題を受け入れて、同じくマイクロの課題を受け入れて運用対処ができるか。

最初のうちはなんでもモノリスになってしまうが、ボトルネックをマイクロに切り分けて対応するのがベストプラクティス。

所感

開発者（チーム）に必要なのは高い技術力や変化への耐性ではなく、心理的安全だと感じた。

26F [同時通訳] CLOSING KEYNOTE

コミュニティの話。
DynamoDBはすごい。
▶️TiDBの話もあった。どう比較するか…。

【著者注】momentoとは

https://classmethod.jp/partner/momento/

発表内ではmomentoの話がなかったので、これが分からないと話が分からない気がする。
執筆時点では残念ながら分かっていない状態で書いているので、見たまま感じたままに書いています。

AWSとMomentoの違いの話か、サーバーレスの課題をMomentoで解決しようという話か。
多分後者かなぁ、と思いつつAWSのサービスの話が出てるので前者にも聞こえる。
主にルーティング関連に強いよ、というのは印象づいた。

APIゲートウェイのルーティングをいい感じにするMomento Topics

図を見るとすごい。
ユーザーはルーティング管理から解放されるからいいぞ！という事らしいので高負荷なサービスになった時に採用する事を検討していく。
▶️今AWSでルーティングがボトルネックまたは管理負荷が高いとMomentoを入れてみよう。

Momento Vector Index

OpenAIのインデックス管理や制御に良さげ

所感

スライドはcacooの3D？どっかで見たことあるな。
AWS EC2がサーバー(VPC)。とりあえずAWSを触ろうとすると慣れないうちはEC2から入りそうだが、これを止めたい！

全体として、momentoとAWSの比較の話だろうか。

懇親会

少しだけ参加していきます。
写真を置いておきます（後日）

全体所感

イベントの随所で参加者を楽しませようとする運営の意図を感じました。
おかげさまでとても楽しい時間を過ごせました。
まさかコーヒーだけでなく、お弁当などの軽食もあったとは！

あまりサーバーレスの知見がないので、ド素人の見解で恐縮ですが、サーバーレスのメリット（AWS？）はイベント駆動＋高いスケーラビリティなので信頼性が高いよ、ということ？
サーバーアーキテクチャだと管理はできるけど、サーバーレスだと別の技術要件が必要になったりする？
そもそもAWS自体にAWS専用の教育コストが発生する事が前提なので、これから新規でサーバーを学習するならどうせやらないとダメな事と割り切れるけど、オンプレミスに慣れている人にとってはサービスを理解するというタスクが新しく降ってくるのでやっぱり受け入れ難さはある。
▶️楽しくなければサーバーレスじゃない。サーバーレスは楽しい

Discussion