ベガスに行くお金がないので、今のところ毎年最大の楽しみのAWS Summitに今年もお参りしてきました。
まあね、AWSも別に慈善事業やってるわけでもないし、ベソスのベネチア貸し切り結婚式問題とか総資産おかしいだろお前。みたいなところもあったりはするけど、それでもやっぱりこの規模のイベントを積極的に打つAWSってユーザーフレンドリーだな、とは思います。
何と比べて、ってそりゃAzureに決まってるだろ、マジでAzure嫌いになったからなｗ
さて、今年もお邪魔したわけですが、しれっと参上落書きボードに名前残してきました。今年は去年みたいなポカをやらなかったので、セミナーはほとんど全部A~Eルームばかりで、一回だけKルームに行ったくらいです。おかげで、企業ブースをほとんど見ていません。セミナー聴講する、たばこ吸いに出る、トイレ行く、戻る。のループを延々繰り返したため、企業ブースはぶっちゃけ二日目のアーキテクチャ道場終わったあとの３０分と、おひるごはんタイムとしてあけていた時間に、ごはん食べたあと見て回ったくらいですが、その時間も７・８ホールのAWSの展示も見て回っていたのでトータルでも企業側は1時間見て回れていないんじゃないでしょうか。
その分、セミナー聴講は聞きたかったのがいろいろ聞けたので大満足です。両日とも基調講演はかなり早く入ったのですごい前の方でしたしね。
Azureなんかをいろいろ触ったうえで、AWSトップがちゃんとビルディングブロックを言及し、説明し、それを形にするのだ、と明言されるとね、やっぱりね、なんていうかね。
Azureマジでクソだな。という思いがふつふつと湧き上がってきますね。
コミュニティと二人三脚してる感がとても強いのよね、AWSは。まあそれは置いといて。
とりあえず印象的だったのを。相も変わらず生成系AIは大盛況ではあったけど、今年を普及の年、と位置付けていましたね。実際Bedrockとかマジで使いやすいしね。何のチューニングもしてないけど、とりあえず自分のシステムに組み込みたい、みたいなときにあれくらい簡単に使えるのはすごいことだと思うよ。まあプロンプトインジェクションとかちゃんと防げよって話なので、適当なプロンプト書くのは間違ってるんで、今後はじゃあそういう適当に作ったプロンプトをどうさばくか、みたいなとこもガードレールとして整備していかなきゃいけないのかもだけど。
それ以外だと今年は結構セキュリティについてチカラ入れてたね、って印象。まあそういうセミナー見て回った、ってのもあるけれど。
・AWS Security Incident Response
まあ昨年のRe: Inventで飛び出したサービス。一瞬MSP各社が変な声出したんじゃないかなぁと思うサービスですが、Summitでも割と声高に叫んでましたね。
まあでもお値段がお値段なので、MSP各社とは競合しないとは思いますが、AWSさんクラスのエンジニア集団にお守りしてもらえるサービス、と考えたら安くはないけどその価値を感じる人は決して少なくない。と思う。だってお前、月額7000$だぞ。100万円/月だぞ。
この金額のサービスが大したことなかったら顰蹙買うわ。
これは何、って話だけど、要するにインシデント管理ツール＋AWSのフルサポート、とくにフォレンジック調査なんかを含めたセキュリティインシデント対応と対策。
セキュリティインシデントのもたらすダメージってのは実際のところとんでもなく大きいわけだけど、それこそターゲットになるかどうかは運みたいなとこもある。
まあ、セキュリティホールだらけのシステム動かしてりゃ運もクソもないけれど、そもそもセキュリティってのは完璧に防御することはできない。なので、インシデント自体は発生を防ぎきる、というのはそもそも思想として間違ってる。システムはいつか壊れる、っていうのと同じで、お前のシステムはいつか、どこかで必ずおもらしする。それが将来的にもないといえるシステムは存在しない。
なあ、檀上に上がってきてたけどな、ドワンゴ。自虐的自己紹介で面白かったよｗ
さて、その時に「何が漏れたか」「どうして漏れたか」「今後どう防ぐか」といったものを調査するのがいわゆるフォレンジックと呼ばれる行為。で、これをきちんとできるエンジニアなんてこの世にほとんどいない。専門企業がたっかい金とってエンジニアが押し寄せてきて何日も調査する、みたいなお仕事なんだ。ちょっと付き合いのあるエンジニアに「インシデント発生したから調べてくれ」って言ってわかることはほとんどない。
これは企業がデカければデカいほど、漏れたもの、の追跡や今後の対策について、精度の高いものを求められる。当たり前だな。
で、DIYでそれやってもいいんだけど、これ契約してるとAWSの専門のフォレンジックチームがあなたのシステムを共同調査します、というサービスだ。そりゃたけぇよ。当たり前だろ。でも1年で1000万くらいでしかない、とかんがえたら、10年以内に一回やそこらはインシデント起きる、って考えて、そのインシデントが小規模ならアレだが小規模で済むかどうかは運、ってなるとそりゃあまあ妥当かもなぁ。って金額ではあるのよ。
AWSが24/365の監視もするし、インシデントのトリアージもする。ユーザー起点で監視にかからなかった障害やインシデントも協力要請出せるし、インシデント管理ツール上で相互コンタクトしながら対応、解決、対策まで伴走して、最終的にはインシデントをナレッジとしてため込んでいく。通知、報告もツール上に用意されている。
要するにMSPをAWSがやります、ってことなんだけど、フォレンジックまで含んでいるのはなかなか剛毅だと思う。各MSPでもフォレンジックまで踏み込んでいるケースはほとんど見たことがないし、まあなあなあでやってるケースはあるとは思うけど、明言して「やります」っていうのは相当勇気が要るので、サービス自体は相当にハイパワーなサービスだとは思う。
トヨタのおもらしを例に出すまでもなく、大企業や金融系のおもらしなんて一撃で億吹っ飛んでも何もおかしくないわけで、年間1000万はまあダメージの10%で被害を最小におさえにいける、っておもったらそこまでおかしい金額じゃない。というかそもそもAWSの利用費が10万ドルを軽く超えるのがほぼ前提条件みたいなもんだし、そんなシステムの時点でそれが生み出している利益は月間100万なんざはした金みたいなもんだろう。
・Aurora DSQL
はい、こちらもマルチマスタ、マルチリージョンのリレーショナルとして登場した例のアレ。Limitelessがマルチリージョンに展開したもの、といえば簡単に聞こえるが、SQLにとっての1msってとても長い時間である、ということを理解できているならば、Limitlessをそのままリージョンまたぎすりゃいいよね、では終われない、ということくらいは普通にわかることだと思う。1msなんて長時間だよ長時間。その上でACIDを成立させるんだろ。キッツいよ。
さて、Limitlessに居なかった存在として調停役があらたに突っ込まれていました。仕掛けそのものはLimitlessのタイムスタンプによる自律判断に近いのだけど、commit時に調停が走ってるね。これはLimitlessのときには見なかった子だ。とはいえ、Limitlessにも居てもおかしくはないけど。
構造的にはRepeated Readにするのが素直ですね。実際Repeated Readみたいだし、これをRead Commitedにしてもあまりうまみはない。というか調停がめんどくさくなるだけだ。Read Commitedじゃないとどうしようもない、みたいな仕掛けを使ってるならご愁傷さま。
印象に残ったのはデータベースとはログである、という定義ですね。まさにその通りなんだよね。ストレージをデータベースだと思ってる人が多いけど、ストレージはただの保管用の表現型に過ぎないんだよ。
データベースってのはログさえあるならゼロから再構築できるけど、ストレージだけあっても再構築が成功する補償はない、ということを理解できているかってのは大事。まあ表現型としてのログはかなり冗長でデータ量がデカいんだが、ストレージはある瞬間のスナップショットに過ぎない。
データベースにおけるログ、は過去からのすべての変化、であるのに対して、その中の一瞬だけを切り取った状態がストレージ、なのである。
いや、実に面白かったｗ
・アーキテクチャ道場 実践編
実際にあった事例をもとにアーキテクチャを組む、解説する、というまあいわゆる人気のコーナー。今回は実践編だったので喜々として参加。
２つのケースをもとにケーススタディするんだけど、どちらもあるあるあるあるってなるケースで面白かったっていうか１つ目のケースの解消法がゴリ押しすぎてワロタｗｗｗｗｗｗｗ
いやわかるけど、無駄に複雑化してて、破綻はしてないんだけどこれ運用きっついだろｗｗｗｗ
僕ならこれやるくらいならオンプレ側のDBに手を入れさせろって吠えるな、たぶん。だってどこで破綻してもおかしくないタイトロープ。怖いよ怖い。破綻しないようにエラーハンドリングしてるんだろうけど、運用に引き継いでヒューマンエラー起こされたらと思うと怖い。でもまあよく考えられてる。とはいえDBの問題で答えがアプリ作りましたって言われるのは納得いかねえｗｗｗ DBでどう解決するか考えちまったじゃないかｗｗｗｗ
２つ目は金融系。まあ金融系（だけじゃないが）お得意の独自仕様の嵐をいかにさばくか。フロント側は別にまあいつものスケールセット＋DRなんでまあいいとして、緩衝地帯になってる中継のとこもうちょっと詳しく聞きたかったな。
BGPって言ってたからDirectConnectベースで重み付けルーティングと個別接続用のなんかを並べたんだろうけど、固定IP系とか名前ベースが使えない、とか独自プロトコルがセッション張ってきます、なんてのはオンプレの遺産にはどこにでも転がってるので、バックドアのほうをもっと聞きたかった。
・Step Functions
いやいやいや。今更何を。って思うかもしれないが、まあしばらくステートマシンについては適当にジョブ回す程度しか使ってこなかったんですよ。だってうち開発じゃないし。インフラだし。
で、まあそれでもSIerさんとお話しする際にStepFunctionsをどこまで使うかとか、Developer試験でもちょいちょい顔出すし、一回まじめに聞いとくか。って感じで聞きに行ったんですよ。
…俺の知ってるころのStep Functionsじゃねぇｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
なんかアホみたいに関数増えとるｗｗｗｗｗｗｗｗｗｗｗ いやね、GUIでなんか増えたなぁとは思ってたけどまじめに使ってるわけじゃないから、まともに見てなかったんですよ。Lambda呼んでエラーハンドリングしてチェインしてくれりゃそれでよかったんで。
こんなんもうステートで分岐処理できる汎用パイプラインじゃん。いや、もう列挙されてる関数見るだけで、StepFunctionsでアプリケーションが作れる、ってのが直感的に理解できる。下手すりゃLambda呼ばなくても作れる。
呼び出すタスクもパラで呼べるのは前からだが、なんかイテレーション増えとる気がする。ステートループせずにマップ張って並列で相互影響のないイテレーションするのか。やべえ、超楽しそう。
変数もスコープとか言い出してるし、こんなんもう一つのライトウェイト言語だぞｗｗｗｗｗ
ついでにAPI呼べるんだもん。ねえ。SQL API呼べるってことだろそれ。
つまり、Lambdaにコネクション張らせなくてもSQL API経由でRDS叩けるってことよな。まあそんな面倒な作り方する理由は基本的にはないんだけど、インフラ屋のジャックナイフとしては相当優秀な部類だぞこれ。関数間の呼び出しが引数じゃなくてRESTとJSONでパラメータ渡す関数呼び出し、ってとらえて、ワークフローがプログラムのフロー図そのまま、内部で戻れば再帰、ステートで分岐するから基本全部にTry ～ Catch入ってる、って考えればもうこれいっぱしの高級言語だよ…。
実際AWS展示ではStepFunctionsで作ったアプリ展示してたが、いやもうそりゃあの関数みりゃできるよ。実装でもLambda呼んでねぇし。APIアプリ提供して、フロントはJS+S3ってか。
API Gatewayのバックエンドに「とりあえずStep Functionsのステートマシンにつないで、初手でパスで分岐する」って言い放った時点で吹きそうになったわｗｗｗｗｗｗ
そうよね、それ出来るわ。うん、いわれりゃできるのわかるけど、ちょっと普通の生活の中では思いつかなかった。頭固まってたねぇ。
だってシンプルにしたいじゃん！ ステートマシンは一つの仕事をきれいに終わらせるステートマシン、ってイメージがあるじゃん！ｗｗｗ
APIのupdate/delete/insert/selectを全部一つのステートマシンで、とかイメージとずれたんだけど、結局それぞれのメソッドから別のステートマシン呼べばいいよね、っていわれたらホントその通り。
なんか変なバッドノウハウかもしれないけど、インフラ屋のジャックナイフなんてそんなもんばっかりだｗ
ほかにもいろいろ聞いてたんですが、特に印象に残ってるのはこの辺りが個人的なインパクトでしたね。特にDSQLはリリースからもうほんと内部構造知りたくてしょうがなかったので。おもったほどLimitlessから大きな変更入れてないけど、うまいことやってるな、という印象。調停くんがシャーディングしている以外は完全パラレルなので、スケールも問題ないし。
あと、地味によかったのは認定者ラウンジがなくなって、ラウンジが自由利用になっていたので、その関係でステッカー配布が独立したこと。おかげで基調講演聞いたらステッカーもらえない、がなくなった。今年は無理だろうと思ってたんですが、無事に全部もらえてよかった。
あと全冠の方々はクソダサい金色のジャンパーもらってたので、あまりのダサさにクッソ欲しくなりました。アレ持ち歩くのは割と晒し者状態じゃないかという気がするんですが、ダサすぎるのでかえって目立つうえにこの会場にいるやつは大体全員それの価値がわかるので、目立ってなんぼ感がすさまじい。超うらやましいｗｗｗ AI/MLの基礎学習がんばろｗ
そんなわけで今年も面白かったです、皆様お疲れさまでした。いつか出展側に回りたいなぁ。
あ、あと最近毎度のごとく居るCatlog様、その東京猫様のジャンパー売ってください。超ほしいｗｗｗｗｗ
