めもおきば Advent Calendar 2024やる

今日から毎日なにか書いていく予定地

adventar.org

 

あ、今年も、モヒカンSlackの「#advent-calendar-2024」でQiita Advent CalendarとAdventarの全てのカレンダーをフィード購読しておいたので、垂れ流ししたい人におすすめです。

qiita.com

 

サーバーレス技術の今と未来についてServerlessDays TokyoのPreEventで話してきました

Serverless

𝕏にURL貼れなくなっているので、Zennにもマルチポストしています。

ServerlessDays Tokyo 2024 PreEvent

2024-09-21のServerlessDays Tokyo 2024にむけて、去年に引き続き、直前イベントでサーバーレス技術の今と未来について話してきました。

いよいよ明日からメインイベントですので参加お待ちしています！

Serverless Update 2024 文字起こし

スライド全体はDocswellさんで公開しています。

PreEventはYouTubeでアーカイブがあります。

サーバーレスのおさらい

「サーバーレス」は、誤解を招きやすい技術用語で様々な定義がありますが、ここでは2つの視点で定義します。

運用者の視点としてのサーバーレスは、物理的なマシンや仮想マシン、EC2インスタンスのような「サーバー」を自分で管理するのではなく、その管理をクラウド事業者に任せるという考え方で、要するに完全従量課金型のフルマネージドサービスであることです。つまり、使った分だけ料金を支払い、リソースは自動的にスケールされる、まさに「0円からいくらでも使える」サービスを指します。 これが最も一般的に言われているサーバーレスの定義でしょう。

開発者の視点で考えると、個々のサーバーの存在に依存しないプログラミングモデルがサーバーレスという技術ムーブメントの重要な要素です。WordPressのアップロードファイル保存先のように、ファイルシステムやプロセスのメモリーといったリクエストをまたいで共有されるサーバー上のリソースに依存しないということです。

AWS LambdaやAzure Functionsのようなプロセスやファイルを共有しないプログラミングモデルがその代表例ですが、Database as a Service（DBaaS）など、裏側で分散システムのテクニック（レプリケーションやシャーディング）を使いつつ、保存先のサーバーを意識せずSQLのような言語で開発者が操作できるようなものも、サーバーレスなプログラミングモデルの一つと言えます。

まとめると、サーバーを所有しないという運用の視点と、サーバーに依存しない開発を意識する視点の2つがポイントです。

「サーバーレス」の全体像

サーバーレスと言われている技術ムーブメントとしていろいろな試みが行われています。それを、先ほどの2つにもうひとつ加えた3つの視点から整理します。

  • フルマネージドサービス
  • プログラミングモデル
  • イベントドリブンアーキテクチャ

小さな課金単位、AWS Lambdaではリリース当初に100ミリ秒単位で課金されていたのが、今は1ミリ秒単位で実行時間に対して課金されるようになりました。大昔の仮想サーバ、EC2では1時間単位の1台単位で課金をされていたのが、今や1ミリ秒でメモリも128MBごとの単位で課金されます。クラウドコンピューティングの特徴として言われるように、確保した量ではなくて使用した量という考え方の変化を表しています。これが完全従量料金というところに表されているわけですね。

サーバーレスなサービスを実現するために、フルマネージドサービスとして、例えばこの弾力性という観点では、クラウド事業者がこの裏側で動いているマシンを増やすオートスケールだったりとか、あるいは使わない時は0台まで減らす、つまり使わない時にはリクエストが来ない時には割り当てマシンを0台にするといった、「ゼロスケール」と言われる動作をします。

1リクエストごとに動く処理として、ファイルや仮想メモリのあり方といったリソースの抽象化、仮想化みたいなところも、コンピューターサイエンスの文脈に綺麗に乗っています。例えばAWS Lambdaだとアカウントをまたいでリクエストが飛ばないように、あるいはメモリが共有されないように、microVMだったりとかコンテナランタイムで分離したりとか、最近だと例えばNode.jsのJavaScriptのサンドボックスを使ってプロセスごとにちゃんと隔離をしてお客さんのデータ、動いているプロセスのメモリを守るみたいことをやっています。

その一方で、セキュリティを守っていくために1リクエストごとにいちいちプロセスを全部1から立ち上げているんだと、やっぱり時間がかかってしまうので、そういったスタートアップの高速化のテクニックというところが色々と試みられています。

そういった中で、やっぱり1リクエストごとにプロセスもファイルシステムも共有されないというのをそのまま書くのはやっぱりなかなか辛いので、プログラミングモデルとしてどう開発をやすくしていくかとして、開発者として一番実現したいのはお客さんの、プログラムを使う人への価値をちゃんと上げていくことが大事になるわけです。

面倒くさいところはライブラリーだったりフレームワークだったり、あるいはクラウドベンダーが管理しているマネジメントの仕組みというところにうまく載せてあげたいので、いろんなシャーディングとかレプリケーションみたいな、データを保存するレイヤーだとそういった分散システムが必要になります。そういったものも全部隠蔽しようというのが、当然の動きとして出てきます。

例えばDatabase as a Serviceのような形で提供されたり、抽象化のグラデーションとして例えばAWSで言うとStep Functionsみたいなものがあります。Step Functionsの記述言語「ASL」なんかは、去年のパネルセッションでも色々な愚痴が出ましたが、ASLみたいな独自の言語、こういった特化型用語をDSLと呼びます。DSLとして抽象化したり、あるいは抽象化をどんどん下げていき、最終的にはコンテナーまで広がっているのかなというのが昨今のサーバーレスの話です。

コンテナというところから、あるいは関数というモデルがあったり、ASLのようなDSL、独自言語があったり、突き詰めて言うとコンフィギュレーション、YAMLだったりJSONの設定ファイルというところに最終的にはいきます。設定まで行くと、用意された設定項目しかできないのですが、そういった自由と抽象化のグラデーションがあります。

そんな感じで、DSLとかを使ってStep Functionsで例えば処理を実行しようとなると、この時にStep FunctionsとかApache Airflowとかそういったものを使ったことがある人だと、イベントドリブンに非同期にシステムを使って繋げていくという設計が大事になります。

例えば分散システムの複数サービスをイベントで繋げていくためには、どういう風に管理するかというところで、オーケストレーションだとかコレオグラフィーみたいなキーワードも出てきます。あるいはシステムをまたぐ間の認証や認可の連携をどうするのか、そういった問題とかもあります。複数の細かい分散システムがある中で、データの整合性をどうやって取るのかみたいな話から、リアクティブシステムみたいな考え方の上に、アクターモデルみたいな考え方が出てきたりだったりとか、イベントドリブンのアーキテクチャーというところをどう実現していくかがあります。

ここまでフルマネージドサービスというところからスタートして、プログラミングモデルを色々考えつつ、その上でいろんなシステムを作っていくためには、イベントドリブンのアーキテクチャーというところの解像度を上げていく必要があるというところまで、サーバーレスの全体像として話をしました。

去年のサーバーレスアップデート2023で、イベントドリブンアーキテクチャの話をさせてもらいました、いろんなクラウドサービスをどう管理するかというところ、LambdaやAzure Functionsで繋いでいくみたいな生で繋げていくという考え方はやっぱりもう古くなりつつあるというか、面倒くさいわけです。例えば失敗した時に再送したりとかということを考えると、いろんな賢い道具が増えているので、例えばEventBridge Pipesだったりとかみたいなそういう道具が増えてきているので、そういったものを使っていきましょうという話を去年させていただきました。

詳しくは昨年のスライドを参考にしてください。

今年は新しいキーワードを持ってきました。

AI拡張型開発：LLMによる開発

AI拡張型開発というキーワードが出てきています*1。

プログラムを自分で全部1から10まで書いてきたのが今までのプログラミングです。もちろんコードジェネレーターのようなものも使われてきましたが、より積極的にAIにプログラムを書かせよう、あるいはそもそも処理そのものをLLMのプロンプトとして記述・実装しようみたいな試みがされています。

ここでいくつかの例を挙げます。

UIではVerceoのv0、GoogleのAI Generated UIのような、プロンプトからUIを定義できる事例が出てきました。 処理の本体そのものを、ローコードとして、その「コード」の部分もLLMのプロンプトで書いてしまおうというのが、AWSのApp Studioかなと思います。 AIのプロンプトから直接動かすのではなく、プログラマとペアプロ的にコードを書いてもらうのが、皆さんおなじみGitHub Copilotですね。

面白い試みとして、そもそもLLMが理解しやすい中間言語を書かせるSudoLangという試みもあるようです。ほかにも、要はデータの形ををLLMに教えておいてSQLをLLMに書いてもらおう、というPostgres.newだったりとか、あるいは古い塩漬けになったコードを更新するのをLLMに任せるAmazon Q Code Transformationみたいな試みがあります。GitHub Copilotとか使った人は試したことがある方もいるかもしれないんですが、LLMは既にあるコードの意図を読み取らせるみたいなところも結構得意だったりするので、そういったところを元にして古いコードを今のライブラリーとかに書き換えてもらうわけです。

というわけで、いろんなAI拡張型開発というのが結構盛んになってきたのかなと思います。

コストに基づいたアーキテクチャ

この1年で特に注目を浴びているのが、コストに基づいたアーキテクチャという考え方です。

よく考えると当たり前の話ですが、巨大なクラウドほどコストの小さな改善から受ける影響というのはもちろん大きいわけですね。要は絶対金額が多いからですし、さらに今後10年間でデータセンターの電力消費量が今の2倍以上に増えるという予想が今出ています。

クラウドの市場規模は非常に大きく、その最終的なコストはデータセンターの電力消費量に行き着きます。そこを例えば1%減らせるだけでも巨大な金額になるわけです。この1%でも性能を良くするという最適化によって、利益が増え、例えば機能拡張などの成長の原資に繋がるという、大きなクラウドほど正のフィードバックが顕著になります。

去年のAWSのre:InventにおけるWerner Voegels氏基調講演で、コスト構造というのがアーキテクチャ設計における重要な要件の1つになるという、The Frugal Architect*2という整理が紹介されました。このような文脈を考える上で1つ例を挙げると、共通機能のコストがあります。

例えば、AWS Lambdaは「ゼロスケール」だと言われていて、使ってない時には1円もかからりません。でも実際には、リクエストが来た時にそのHTTPのリクエストを受け取るロードバランサーが存在したり、あるいはログの基盤とかも動いている必要があります。「リクエスト」が来ていないからといって、その本当に0にはできないコストというのは、どこかにあるわけです。

そういったコストはクラウド事業者が実は無料で負担してる場合多いと思います。その一方で、Momentoさんのような「本当のサーバーレス」を謳うクラウドベンダーでは、いわゆるこうマルチテナントを前提とすることにより、みんなでそういったコストを負担していくというモデルというのが、1つアーキテクチャの設計としてあるわけです。そんなアーキテクチャを、私自身の言葉で言うと「広く薄いアーキテクチャ」と昔から呼んでいます。

というわけで、コストに基づいてアーキテクチャーを決めるという視点を持っておくと、今後のサーバーレスに限らずクラウド事業者の動きをより深く理解でき、未来の予測がしやすくなるでしょう。

NewSQLとDBaaS

この何年かで、NewSQLなどを言われる新しいデータベースサービスが、Database-as-a-Service(DBaaS)というクラウドサービスとしてさらに普及してきています。これを3つの軸から整理してみました。

1つはプロトコル互換です。全く新しいプロトコルによって提供されるサービスもありますが、DBaaSで存在感が大きいものは、PostgreSQLやMySQL、MongoDBなど既存のオープンソースデータベースにプロトコルを合わせて出しています。プロトコルを合わせるということは、同じ機能が同じように使えるわけです。もちろん、性能特性などデータベースの性質や特徴というのは違いはありますが、表から見たいわゆる機能的な機能というとプロトコル互換というところで1つ見えるのかなと。

次はマルチモデルな計算機層（コンピュート層）です。AzureのCosmos DBや、GoogleのSpannerでは、いわゆるSQLとかドキュメントDBみたいな形だけではなく、同じ枠組みの上でグラフDBや、最近だとAIの文脈でよく使われるベクトル検索、あるいは全文検索など、様々なデータモデルを扱える処理層を乗せられるというのが、最近のトレンドの1つになっています。

最後に、ストレージと計算機層の分離というコンテキストにおけるストレージの話です。 例えばオブジェクトストレージから直接クエリーができる。今までもAmazonだったらAthenaがS3から直接クエリを投げたりできました。AmazonのAthenaがS3にクエリできるのはそりゃそうだよねって感じですが、例えばBigQuery Omniが直接Amazon S3からクエリできるような、他社ストレージに直接クエリできるようなデータベースサービスが出てきています。あるいは独立したオープンソースとして、DuckDBは、シングルバイナリーで動いてS3からファイルを取ってきて直接クエリができるみたいな、そういう新しい動きというのがあります。

今後に向けてひとつ覚えておくと良いのが、マルチクラウドとクロスクラウドという考え方です。 たとえばメインのウェブサービスの基盤はAmazonで動かしているけれど、集計のところだけBigQueryに転送しているといったパターンは以前から良く聞きますが、それぞれ全てのクラウドを使える状態にないとサービスが劣化してしまうという点で、マルチクラウドは可用性の観点から厳しいところがあるという見方がありました。このマルチクラウドからもう1歩さらに踏み込んで、データがどこにあってもいいよみたいな、クロスクラウドという考え方が増えて行くのではないかと思っています。

というわけで、これらの考え方の整理というところで、プロトコルの互換という話、プロトコルの話と計算機層とストレージ層という3つに分けて考えると、DBaaSがこれだけ広く出てきている理由について整理できるのかなと思っています。

フロントエンドとバックエンドの接点

昨年のServerless Updates 2023ではHonoを中心にしたCDNの話をしました。

フロントエンドとバックエンドの接点というところで、これはCDNエッジコンピューティングやAWS LambdaなどのFunction as a Serviceに限らず、新しいプログラミングのパラダイムで新しい「Ruby on Rails」を探そう、新たなレールはどう敷いたらよいだろう、というのが今まさに今模索の段階にあります。

この1年の動きとしては、例えばNext.jsがフロントエンドを中心にしたコードの中にサーバー側のクエリの実装を埋め込むServer Actionsだったり、昨年も紹介したHonoはウェブスタンダード技術（fetch()やJavaScriptの標準関数、標準インターフェース）に則った枠組みをベースに、NodeやDenoといったバックエンド側の技術からスタートしてフロントエンド側にどんどん浸透していくみたいな、こういったいろんな双方からの動きっていうのがあります。

バックエンドもフロントエンドも、最終的にはデータをどう扱うかというところがサービスの1番大事な部分ですが、データをどういう風に守っていくか、もう少し踏み込んで言うと、そのデータのスキーマをどうやって定義して、それをプログラミング上でどう強制するかといった型安全性のような話が重要です。今までだとGraphQLやgRPC向けにスキーマを作って、それをもとに各言語で自動生成するようなやり方が結構多かった。新しいパターンだと、このNext.js Server Actionsなんかもそうですが、TypeScriptのスキーマをフロントエンドとバックエンド全部で使い大統一するような、tRPCのような試みもあります。

フロントエンドとバックエンド両方にまたがってデータを守っていくために、今までだったらバックエンドでバリデーションかけてフロントエンドも一応バリデーションかけるけど最終的にはサーバー側で掛けるからいいよねみたいな二度手間をしています。フロントエンド側とバックエンド側で実装の詳細が違うと、なんかフロントエンド側ではパスしちゃったがバックエンド側でエラーとして弾かれた時にこれはユーザー体験悪いよねみたいな話になります。そういったスキーマをどう一貫して扱うかみたいなところまでセットで、その新しい「on Rails」を模索していく感じになるのかなと思います。

FaaS Updates

FaaSの分野でもアップデートは色々あります。

AWS LambdaやAzure Functionsではかなり力がかけられていて、性能改善、例えばAuto Scalingの性能がもう何倍にもなったみたいな話や、長時間実行やHTTPのストリーミングなどがあります。 これまでレスポンスの内容はファンクションの戻り値でJSONの全体を一括で返す仕様になっていたのを、ChatGPTの1文字ずつ出てくる体験を実現するために、HTTPのストリーミングとして少しずつクライアントに返すための仕様を、プログラミングモデルとして定義されたというわけです。

開発体験の向上として、例えばAmazonだとサーバーレスアプリケーションをビジュアルプログラミングで構成できるApplication ComposerからIaCのコードを吐き出すみたいな話や、AmplifyのUIといったものが登場しました。Azure Functionsでは今までのNode.jsとかでもとてもプリミティブに、パスごとにファンクションを用意し、それぞれのファンクションがたとえばJavaScriptのオブジェクトでレスポンスを返してましたが、新しいプログラミングモデルとしてExpressのようにパスとレスポンスを定義できるといった開発体験になりました。

AWSでおもしろい動きでいうと、いわゆるオープンソースソフトウェアをマネージドで提供するものが結構増えています。、例えば以前Kinesis Data Analytics for Flinkのような名前で提供されたものが、今Amazon Managed Service for Apache Flinkみたいな感じでリブランディングされています。Flink以外にも、Amazon Timestream for InfluxDBとか、Amazon Managed Workflows for Apache Airflowのような、これらはそこまでサーバーレスっぽくはないのですが、マネージドオープンソースソフトウェアというのが結構Amazonでも提供が増えてきてるように感じています。 今までだとAmazonは独自路線で最初から最後まで新規に自社設計した「新しい画期的なサービス」を提供するパターンが多かったように思いますが、最近はオープンソースに注力してるように感じます。例えばFaaSと関連が深いものとしてはKafkaです。今までだったらKinesis Data StreamからLambdaにつぎ込むみたいなパターンがメインでしたが、今だとKafkaのマネージドサービスであるMSKへの統合に対して深く対応してきているなと感じます

一方それと真逆というか全然違う動きをしてるのがGoogleです。皆さんご存知の人も多い通り、Google Cloudはやっぱりコンテナをベースに成長してきてるので、Google Cloud Functionsは今Cloud Runに完全統合されてCloud Run Functionsに統合されました。元々Cloud Functionsが第2世代になった時からほとんどCloud Runでしたが、完全にCloud Runに統合されたので、例えば今年入ったGPUの対応がCloud Runに入りましたが、ファンクションからGPUを使ったコードが書けるようになりました。まだ使うところは限定的ですが、それでも音声合成とかではGPU積極的に使えるます。これからどんどんAIのモデル、小さな言語モデルみたいなものが今後増えてくると、このようなGPU対応もかなり生きてくる場面が増えてくるでしょう。

共通して言えるところは、各社開発のしやすさに注力してきてるということです。去年もコンテナ技術との統合の話はしましたが、コンテナ技術をファンクションと統合していく流れは今年も引き続き続いてるのかなと思います。

まとめ

FaaSそのものについても引き続き完成度を上げているのは続いていますが、今年いくつかの視点として、4つの話をしました。

AIをどんどん積極的にコード生成させたり、LLMプロンプトをコードそのものとして使うといったAI拡張型開発が出てきています。

コストに基づいたアーキテクチャっていう考え方。なぜ1%でも性能を良くする必要があるのかどんなインパクトがあるのかを考えると、クラウドベンダーが最終的には電気を負担するってところがコストそのものなので、そこにそこを考えていくといろんなアーキテクチャの技術的選定が腑に落ちるのでは無いかと思います。

DBaaS、もちろんデータベースに限らず、例えばMemcacheのようなメモリキャッシュや、Pub/Sub基盤などもありますが、そういったデータストア系のサービスがクラウドサービスとして提供される中で、マルチクラウドとして複数のクラウドを単に併用するだけではなく、クロスクラウドという形で、クラウドをまたいでデータを共通化して使うといった考え方、あるいはクラウド同士でデータを、例えばS3からGoogle Cloud Storageに全部引っ越しても同じような計算機層あるいはプロトコルが使えるといったクロスクラウドの考え方が今後重要になるでしょう。

というわけで、このファンクションサービスの紹介と、サーバーレスを寄り深く知るための視点として4つキーワードを今年は紹介させていただきました。

ServerlessDays Tokyo 2024

ServerlessDays Tokyo 2024まだまだ参加募集しているのでぜひお越しください！

*1:https://www.gartner.co.jp/ja/newsroom/press-releases/pr-20240603

*2:https://www.thefrugalarchitect.com/

2023冬コミのおしらせ

コミックマーケット103（2023冬コミ）に参加します。

おしながき

新刊：TechReport 2023.12 500円

めもおきばTechReport 2023.12

今回は3つの記事でお送りします。

【サーバーレスの次はなんなんだ】
現状をおさらいしつつ、サーバーレス技術の少し先にある姿をいくつかのキーワードから予想していきます。

【私もSecHack365に参加したい！】
たまにハッシュタグで流れてくる謎のU25長期ハッカソン「SecHack365」について、中の人の視点からどんなイベントなのか紹介します。

【2023年振り返りと2024年技術予想】
様々なキーワードからトレンドの少し先の技術について紹介します。
今回取り上げたキーワード：メガクラウドと特化型クラウド／ハイパーバイザーのSoC化／ライセンスとクラウドベンダー／イベント駆動型API／LLM時代のAIペアプロ力／生活必需品としてのGPU・NPU／Passkey／ウェブアクセシビリティ／リアルイベントの再開

 

委託新刊：付け焼き刃のQUIC入門 概要/フォーマット/暗号化編（on-keydayさん） 1,000円

付け焼き刃のQUIC入門 概要/フォーマット/暗号化編

QUICのRFC、仕様をベースにいろいろ細かいところに突っ込んでいます。 (逆に背景事情についてはタイトル通り若干付け焼き刃です)
特に2章のプロトコルフォーマットでは自分がRFCを読んで「定義と記述がまとまってて ほしかったな」と思っていたのを反映してできるだけ各フレームやパケットがどんなところで使われているかを入れつつ解説しています。
3章にはちょっとだけ自分が実装したコードを入れて説明しています

QUICのちょっと詳細を知りたい方やQUICのRFCを読んでみたい方にとって
本書が役に立てたら幸いです。

そのほか既刊

いつもの本も持っていきます。冊数そこまでないので、紙の本を入手したい方は取り置き連絡頂ければです。

  • Serverlessを支える技術 第4版 1,000円
  • TechReport 2022.12 500円
  • TechReport 2022.08 500円
  • 総集編 Vol.1 1,000円
  • 総集編 Vol.2 500円

 

 

技術書典15と技書博9に参加してきました

技術書典15

techbookfest.org

11/11～11/26のオンラインマーケットと、11/12に池袋サンシャインシティで行われたオフライン会場で参加してきました。

今回は完全に新刊なにも無しという状況だったので、新刊があるか来てくださった方にはとても申し訳なかった一方で、既刊を買っていってくださった方も多く、コロナ禍を抜けて再び人と本がたくさんの技術書典が戻ってきたなという感慨がありました。

まだ電子書籍分はダウンロードもできていないのですが、オフライン会場で物理本を出されているサークルさんからごっそり新刊をいただいてきました。

このあとオンラインマーケット頒布の物理本もぽちぽちしたので、12月に届くのが楽しみです。

技書博9

gishohaku.dev

だれも正式名称「技術書同人誌博覧会」で呼ばない技書博にも参加してきました。こちらは蒲田PiOで現地参加です。京急蒲田駅からすぐなのが良いですね。

こちらも新刊という形ではなかったのですが、フリーペーパー企画にのろうと当日朝に一気に作りました。フリーペーパーはそのうち公開しようかなと思っています。

正直、頒布冊数でいうと参加諸費用ギリギリという感じですが、まあこれはうちのサークルに興味がある方はだいたいすでに既刊を買っていただいているというのもあります。そのかわり、色々な方とゆっくり話ができたり、中央のステージで出版社の編集さんのパネルセッションがあったりなど、「技術書」を介したコミュニケーションに特に力が入っているイベントです。

私自身も同じく他のサークルさんの本をすでに技術書典等でいただいているのがほとんどでしたが、取りこぼしも含めてやはりそこそこ買っていましたね。

技術系同人誌を頒布する機会は、コミケ、技術書典、技書博とだいたい3つが大きなものとしてはあるのですが、どれも色が異なってそれぞれの価値をあらためて感じました。

今後も引き続きこの3つは全参加で行く予定なので、どうぞよろしくお願いします。

 

 

 

#ssmjp で最近のサーバーレスの話をしました

Serverless ssmjp

2/16のssmonline #32にて、「最近のサーバーレスの話」を話してきました。

スライドはこちら：

最近のサーバーレスの話 #ssmjp by @nekoruri

 

おさらい：サーバーレスってなんだっけ？

まずは軽くおさらいからです。

サーバーレスは性質をあらわしているので0／1であてはまるものではないですが、やはり完全従量課金という課金モデルに近づける努力をしているものをそう呼んでいきたいところですね。

最近のサーバーレス開発

サーバーレスといえば、FaaS（AWS LambdaやAzure Functions）で様々なサービスをイベントドリブンでつないでいくアーキテクチャが注目されてきました。「もう古い」はちょっと盛りましたが、単純にFaaSで処理をつなぐのでは、そういったイベントドリブンな「ピタゴラ装置」を管理するのが大変です。

失敗時の再送や、異常データの除外（DLQへの積み替え）、イベントデータの書き換え・詰め替え、条件によるフィルタリングなど、イベントドリブンなシステム設計をする上で共通で必要そうな機能もはっきりしてきました。

それらを「オーケストレーション」と「コレオグラフィ」というふたつのアーキテクチャパターンから管理しやすく整理しようというのが現在の大きな流れです。

オーケストレーション型の管理

ワークフロー全体を一つのサービスの上で定義して様々なサービスを組み合わせるAmazon Step Functionsなどは、見方を変えれば中心となるオーケストレーターが他のサービスを呼び出す「オーケストレーション型」です。比較的密な結合をすることが得意です。

その一方で、より疎な結合をしたいのであれば、FaaSを挟むかわりに、イベントバスを介して接続するというパターンが増えています。これは中央集権的な管理ではなく「コレオグラフィー型」と言えます。イベントバスは技術的な要素としては賢いPub/Sub基盤ですが、イベント処理のための機能が盛りこまれています。

FaaS Updates

もちろんFaaSの仕事はサービスをつなぐだけでは無いので、FaaS自身も様々な拡張がされています。この数年の大きなアップデートをまとめたのがこのスライドです。コンテナとの融合や、対応言語の拡充は各社共通しています。同時実行数の制御など、弱みとされていた点もつぶしてきています。

FaaSの開発もいろいろ課題がありましたが、ここで「小ネタ」として紹介したように、地味にいろいろ改善がされています。少し前にためして辛いなーと感じた人もあらためてためしてみるチャンスです。

FaaSの次の戦場：CDNエッジ

いま一番ホットな戦場のひとつが「CDNエッジ」です。なかなかに技術的制約の強い環境ですが、フレームワークなども登場してきたことで一気に開発者体験が良くなってきました。

まとめ

これでサーバーレス分野に興味を持った方むけに、「Serverlessを支える技術」で詳しく解説しているので、よろしくおねがいします。

SecHack365 応募受付中

SecHack365

https://sechack365.nict.go.jp/og/ogimage22.png

情報通信研究機構（NICT）では、25歳以下のエンジニア向けに若手セキュリティイノベーター育成プログラム「SecHack365」というのをやっています。

sechack365.nict.go.jp

いままさに2022年度の参加者を募集していて、5月10日の12時までということで募集期間も残り少ないのですが、あらためて宣伝です。

SecHack365について

詳しいことは開催概要をみて欲しいのですが、（今のところ）オフラインのイベント（4回）と、オンラインのイベント（2回）をまぜる感じで、来年3月の成果発表会に向けて6回のイベントがあります。5つのコースと、もう少し細かくわけたゼミごとに、イベントに限らず年間を通していろいろな形で支援をおこなっていきます。

コース・ゼミごとですすめかたが結構ちがうので、そのあたりはコース概要をご一読くださいませ。

仲山ゼミについて

例年「開発駆動コース」にてゼミを担当しています。

詳しい内容や、過去の修了生の作品などは、こちらにまとめてあります。

nekoruri.notion.site

この「仲山ゼミ」では、新しい技術を世の中に拡げることで世界を変える意欲がある人を募集しています。「この技術はすごい！自分ならこう活かしたい」というような開発テーマをすでに持っている人をターゲットに、まずは持ち込んだ開発テーマを進めてもらいながら、SecHack365をフルに活用し、自らの定めたビジョンに向けて走りながらそのテーマの方向性や、最初に見えていたゴールのその先を、表現と対話によって模索していきます。

たとえばこんな人を募集しています。

・サーバーレスでセキュアなアプリケーションを実現したい

・セキュアなウェブを支える技術スタックを改善したい

・新しい世界観を実現するウェブサービスを開発したい

これ以外でも私がサポートできそうなテーマは採用しますので、まずはぶつけてみてください。

私は決してELFバイナリがすらすら読めたりハイパーバイザーを書いたりするような優秀なセキュリティエンジニアではありません。ですが、トレーニーがやりたい事を様々な視点からどうやって拡げていくかという助言には自信があります。

自分が注目している技術の力で世界を変えたい人の応募をお待ちしています！

ポイント

あちこちで言ったり書いたりしていることをまとめておきます。

  • 応募課題はコミュニケーションです。私達に伝えたいと思っていることを漏れなく書いてきてください。
  • 技術力や表現力はこの1年で磨いていけます。でも、取り組みたいと思っているテーマについて、自分がどう考えているのか知っているのはあなただけです。あなたは、どんな技術が好きで、どこを面白く感じていて、それを使って何をしたいと考えていますか？その技術の力で、どんな世界を作っていきたいですか？
  • 技術的現実感を持ちつつ、夢は大きく！

というわけで、残り2日ですが、よろしくです！

 

 

 

LayerXに転職しました

まる6年お世話になったWHEREを退職し、2月からLayerXではたらいています。

WHEREでの6年間

だいたい3年くらいで転職していることが多いので、6年というのは過去最長でした。まあうしろの2年くらいはほとんど成果が出せていなかった(後述)ので、実際の長さとしてはそれほど変わらずかもしれません。

WHEREでは、ちょうど自分が入ったタイミングではじめたIoTビジネスにおいて、デバイス管理のためのデータ処理基盤を担当していました。

いわゆるお客さんに面するSaaS本体の部分は内部APIを介して別チームが見ていて、実際のデバイス側と向き合ってデータの送受信を受け持ち、センサーデータの一次処理などもここでやっています。Bluetoothメッシュネットワークを活用したEXBeaconという独自デバイスも作っていたので、立ち上げ期はエッジ側のゲートウェイの実装とかも見ていました。ウェブエンジニア10年以上続けてきて、ここでまさかのC言語を仕事で使う事になるとは。

当時自分ひとりチームだったということもあって、アーキテクチャについては自由にやらせてもらい、FaaSとPubSubを中心にしたフルサーバーレス構成で組んでいます。当時はまだ今ほどサーバーレス開発の道具が揃っていない状況でしたが、IoTデータ基盤というのは、高頻度に集まってくるデータを時系列データ処理していくというのがメインの仕事なので、ひとりチームというのを差し引いても、正しい選択だったと今でも思っています。

つくっていたもののざっくりとした概要は、過去のスライド見ていただければと。

BluetoothメッシュによるIoTシステムを支えるサーバーレス技術 #serverlesstokyo by @nekoruri

FaaSで小さくはじめるIoTリアルタイムデータ処理 #serverlesstokyo by @nekoruri

IoTとの通信部分は、まだリリースしたばかりのSORACOMを活用していました。ちょうどSORACOM Funnelもリリースされたばかりで、立ち上げ時期にいろいろと楽をさせてもらいました。

どれだけFunnelが好きかはこちらの記事をご覧ください。

d.nekoruri.jp

いわゆる情報システム担当も兼務していたので、IDやデバイスの管理をしたり、情報セキュリティにまつわる社内ルール作ったりプライバシーマーク取ったり、そういったものも担当していました。

ちなみに前回の転職エントリはこちら。

d.nekoruri.jp

うつ病と転職

まあそんなこんなで2016年からいろいろやらせてもらっていたのですが、2019年頃からうつ病を再発しまして、そこに2020年からのコロナ禍が直撃し、思ったように働くことができないという状態が続いていました。会社のステージとうつ病の改善というところが噛み合っていないというのが根本にあり、このままだらだらと続けてもお互いに良くないなと思い、転職することにしました。

ありがたいことに、「うつ病の寛解と転職をセットで」という希望を伝えた上でお声掛けいただいた会社さんと話をさせてもらい、最終的にLayerXに参加することにしました。

LayerXのポイント

きっかけはセキュリティ・キャンプなどでもお世話になったken5先生が居るということで気になっていたのですが、とにかく会社としてのあり方が気に入った、ということにつきます。

「すべての経済活動を、デジタル化する。」というのを会社のミッションにしていて、請求書の受注処理や企業内の申請においてきちんとITを活用するバクラクシリーズや、資産運用における様々な「負」をITで解決するアセットマネジメント事業、企業や行政の持つパーソナルデータを、法規制に準拠し、組織を横断して安全に活用するための次世代のプライバシー保護技術など、いまのところ3つの分野に展開しています。

bakuraku.jp

corp.mitsui-x.com

www.anonify.layerx.co.jp

内側を見てみると、この規模の会社としてめちゃくちゃに社内ITのセキュリティ統制ができているというのがあり、今までのキャリアを踏まえた上できちんと社内ITをやりたいという気持ちにうまくはまりました。

LayerXをひとことで言うと、「今どきのプラクティスをきちんとやっている会社」です。気に入っている行動指針は「徳」です。やっぱりそれなんよ。

いままでいろいろなステージのIT企業に参加してきたのですが、いわゆる「すごい伸びている最中のスタートアップ」には所属したことがなかったというのもポイントですね。

今後の役割

実は文章で書くと前職とあまり変わらないのですが、社内のITを見るコーポレートエンジニアと、バクラクシリーズを展開するSaaS事業部のSREの兼務です。Terraform書いてます。比重としてはコーポレートエンジニアがメインです。やってることは採用情報を見てください。是非見てください。絶対見てください。

open.talentio.com

open.talentio.com

今のところ、とにかく採用人数が多いうえにトライアル採用などもあるので、アカウント管理まわりを自動化したり、AWSやAzureAD、Google Workspacesなどを活用して安全なガードレールを整備したりといった、他の人たちが気持ちよく安心して仕事できる環境づくりを進めたりしています。

こういったことがどこの会社でも当たり前に行われるようになったらうれしいので、今後どんどん情報共有もしていくつもりです。アウトプットしないのは知的な便秘！

よろしくおねがいします

折角の連休ということで、Meetyも開けました。

あまり人と話すのが得意ではないのでたぶん期間限定になりそうですが、LayerXのことでも、LayerXに関係無いことでも、気軽に声掛けてください。

meety.net

採用も！頑張って進めているので！応募お願いします！！！（平伏）

Â