AWS LambdaとDynamoDBがこんなにツライ時代ではない

ありがたいことに、3年前に#ssmjp 2017/06で話したスライド

をTwitterで紹介して頂いた*1 ようで、当時から大幅に改善しているところを振り返りたいと思います。あと、ついでに最近やっているAzureに関しても少し触れていきます。

サーバーレスアーキテクチャ #とは

f:id:nekoruri:20200607114509p:plain

当時はこう説明したのですが、今でもそんなに悪くない表現かなと思います。

f:id:nekoruri:20200607114853p:plain

書籍は現在「Serverlessを支える技術 第3版」まで出ていますので、BOOTHからどうぞ(隙あらばダイマしていく方針)。

サーバーレス三種の神器

f:id:nekoruri:20200607115055p:plain

今このスライドを作るなら、認証認可の話を入れるかなと思います。システム内のAWS IAMとクライアント側のCognitoどちらも重要です。

ちなみにAzureを含めておさらいすると、こんな感じの対応になります。

勝手にスケールするデータストア

  • Amazon DynamoDB、Amazon DocumentDB ↔ Cosmos DB
  • Amazon S3 ↔ Blob Storage、Data Lake Storage Gen2
  • Amazon Aurora Serverless ↔ SQL Database serverless

勝手にスケールするソフトウェア実行環境

  • AWS Lambda ↔ Azure Functions
  • (AWS Fargate ↔ Azure Container Instances)

それらをつなげる枠組み

  • Amazon Kinesis Streams ↔ EventHubs
  • Amazon Simple Queue Service (SQS) ↔ Queue Storage、Service Bus
  • Amazon Simple Notification Service (SNS) ↔ EventGrid
  • AWS Step Functions ↔ Logic Apps、Durable Functions
  • Amazon API Gateway ↔ (Functions組み込み機能)、API Management

f:id:nekoruri:20200607121752p:plain

この辺は今もあまり変わらずです。

この構成の肝は、クラウドサービスの構成と、関数のデプロイを完全に分けていることです。AWS SAMやServerless Frameworkで普通にやると、関数本体がCloudFormationスタックに入ってしまい、リアルからデータが上がってくる「本番環境」で高速に試行錯誤を繰り返すIoTビジネスの特性とちょっと合わないと感じたので、ここを切り離しました。ただApexがメンテされなくなってしまったので、今ならlambrollですね。

Azureでも同じように、全体の構成をTerraformで行い、関数は別レポジトリからデプロイしています。

サーバーレスあるある選手権 Lambda編

f:id:nekoruri:20200607125048p:plain

f:id:nekoruri:20200607125146p:plain

ログそのものは現状でも余り変わっていないのですが、追いかける部分に関してはAWS X-Rayの登場でだいぶ改善されました。AWSサービスへの外部リクエストは何もしなくても記録されますし、外部サービスや重い内部処理をプロファイリングしたければサブセグメントを生成してあげればX-Rayの時系列トレースグラフに表示できます。

Azureの場合はVSCode拡張からリアルタイムでログを見ることができます。Application InsightsからX-Rayと同じようにサービス間のコールグラフやサブセグメントごとのトレースグラフが見られるのも同じです。

f:id:nekoruri:20200607130253p:plain

ここは今でも変わっていませんが、その後運用して判った部分としてはmemory_sizeの調整になった時点で消費メモリ量が問題になることはあまりない(ざっと見て最大消費量より多ければ良い)ので、余程メモリ変動の大きい処理をしていないのであれば、カスタムメトリクスだして追いかけるほどではないです。逆に言えば、メモリ変動が大きい処理があるのであれば、どこかで仕組みを変えて処理量のほうを平準化できないか考えた方が良いです。

f:id:nekoruri:20200607130738p:plain

f:id:nekoruri:20200607131145p:plain

このスライドの中で状況がもっとも変わった部分です。なんとかしてくれました。

そもそもVPC環境でのLambda起動の仕組みが大幅に改善されました。

ENIを生やしたインスタンスを個別に作成していたものが、基盤側で用意した共有ENIにNATされるようになったので、15秒ほどかかっていたのが1秒前後になりコールドスタートが実用的な範囲になりました。

また、RDSへの同時接続数も、Lambda側で同時実行数が設定できるようになり、RDS側にもフルマネージドのコネクションプーリングRDS Proxyが提供されたので、問題にならなくなりました。

そもそもVPCを使わずAurora ServerlessのData APIを使うという選択肢もできました。

とはいえ、依然としてRedisなどはVPCの中にしか作成できないので、VPCを廃絶できないのがおしいところではあります。

サーバーレスあるある選手権 Kinesis編

f:id:nekoruri:20200607132542p:plain

f:id:nekoruri:20200607133153p:plain

f:id:nekoruri:20200607133208p:plain

ここも大幅に改善されたポイントです。

待ち時間を指定できるようになったので、データが少ない場合の処理効率が良くなりました。

またKinesis Data Streams側のシャード数と掛け算でLambda側の「Parallelization Factor」で並列実行できるようになったため、時間が掛かる処理をぶら下げたときにシャード数まで引き上げずに済むようになったのも地味に大きなポイントです。これまではKinesis側のリミット(1MB/sまたは1,000レコード/秒)より大幅に少ないデータしかないにもかかわらず、シャード一本月1500円(14.04USD)が掛かっていました。

f:id:nekoruri:20200607140510p:plain

きました。使っています。

f:id:nekoruri:20200607140619p:plain

東京には来てくれたのですが、結局うまく処理にはまらずに現状使っていません。

どちらかというと、Apache Flinkで分析処理を実装できるようになった方が個人的にインパクトが大きいです。

イベントソーシングパターンなど、ストリーミングデータに対してステートを持った継続処理を実装するユースケースがふえているのでもっと活用事例が増えて欲しいところです。

サーバーレスあるある選手権 DynamoDB編

f:id:nekoruri:20200607133813p:plain

f:id:nekoruri:20200607140330p:plain

KVSベースでの設計がRDBに比べて違うノウハウが必要となるのは以前通りです。これはもうキーベースで分散するデータストアである以上は逃げられません。とはいえ、サーバーレス開発の普及によって世の中の情報もだいぶ増えてきたので、3年前よりは実感的にはだいぶ始めやすくなったのではないでしょうか。

f:id:nekoruri:20200607133959p:plain

f:id:nekoruri:20200607134017p:plain

f:id:nekoruri:20200607134031p:plain

DynamoDBのコスト問題はまだまだ苦労する部分ですが、オンデマンドキャパシティーモードが用意されたので、リクエスト数が急激にスパイクするようなケースでも安心して使えるようになったのは大きいです。

ただ、オンデマンドキャパシティーモードの方が「単価」が大幅に高いため、常時リクエストがあるようなケースではかえって高くなってしまうこともあり、そこはユースケースと運用コストや障害リスクに見合った選択が必要です。

f:id:nekoruri:20200607135148p:plain

バックアップは完璧に用意されました。オンデマンドもPITRもあります。

注意としては、あくまでバックアップはDynamoDBサービス内にリストア可能な形で保存されるだけです。データ自体をCSVやJSONなどでエクスポートしたい場合は、これまで通りDataPipelineをつかったり、ひたすらスキャンでページを手繰る必要があります。

まだまだ道半ば

f:id:nekoruri:20200607142046p:plain

結局DynamoDBだけでは厳しくなったので、現在ではRedisも併用しています。

このあたりは、先日のServerless Meetup Tokyo #16でも話しました。

f:id:nekoruri:20200607142209p:plain

現在は、お客様や大人の事情に合わせて、上でも書いたとおりAzureとAWSで両刀でやっています。GCPでもだいたいできそうな感触はありますが、案件ください

f:id:nekoruri:20200607142221p:plain

3年前と比べると、大きな障壁はかなり取り除かれ、頑張ればだいたい問題ない、とはっきり言えるところまで来ました。

昨今、ソフトウェア開発の手法で社会や組織を変革し続けるデジタルトランスフォーメーションの波が来ていますが、特にIoTではとにかくサービスデリバリの高速化が重要です。サーバーレスアーキテクチャという選択肢で正解だったというのがこの3年間の最終的な評価です。

宣伝

 

 

AWSによるサーバーレスアーキテクチャ

AWSによるサーバーレスアーキテクチャ

  • 作者:Peter Sbarski
  • 発売日: 2018/03/14
  • メディア: 単行本(ソフトカバー)
 

SPS認定済ソリューションパートナーになりました

私の所属先WHEREが、今更ではあるのですが!ソラコムさんの「SPS 認定済ソリューションパートナー」に認定されました。

where123.jp

soracom.jp

SORACOM-UGServerlessConfなどの技術セッションでも表に出していたのでご存知の方も多い通り、2016年にEXBeaconプラットフォームの実証実験を始めて以来ずっとSORACOMを利用しつづけているのですが、色々と会社としても個人としても良くして頂いていたのでパートナーになるのをすっかり忘れていた、というのが正直なところです😀

SORACOM Beam/FunnelやSORACOM Gate/Napterを中心に、様々なプラットフォームサービスとしても弊社はごりごりと活用している側だと自認していますが、連携強化によってさらに楽しい社会を作っていければなと思います。

世界中のヒトとモノをつなげ共鳴する社会で、
IoTがもたらす真の豊かさを追求していきます!
よろしくお願いします!

soracom.jp

where123.jp

Coinhive事件とその先についての個人的見解

経緯については、Wikipedia見てください。

ja.wikipedia.org

また、裁判の争点に関してはこちらが詳しいです。

www.bengo4.com

 

本件に対して個人的な立場としては、地裁判決を支持しています。

その上で、Twitter上などで自分の感覚と異なる意見もあるため、そのあたりで自分の立場を整理してみます。

まだこまかい論点については自分の中でももやもやしていますし、そもそも宗教上の理由等で違う意見を持つ方も多いとは思いますが、そこは個人の意見としてご理解を。

広告との違い

動作が重く不自由なUIを持つ広告とどこが違うのか、という意見がありました。

Coinhive等に関する問題には、まず「サイレントにやるな」というのと、「消費リソース量が金銭的インセンティブに”比例”する」という二つの問題ががあり、これらの点において広告と同一視して議論するのは違うように思います。

黙ってオプトアウトもできないような状態で勝手にやるな、というのは地裁も高裁も認めているとおりです。

その上で、そもそも広告は画像等を表示してリンク先に遷移させることが目的です。ふざけた広告システムも多いので混乱しがちですが、広告はリンク先に正しく遷移させることが主目的であり、クライアント側もサーバー側も処理は軽ければ軽いほど良いわけです。

例えばそれが「重い」動画再生という形態であっても、少しでも多くの人をリンク先に誘導するために、ブラウザの処理を軽くしたいというインセンティブが(本来は)生じます。その一方でCoinhive等は「より重くすること」そのものに直接価値が生じてしまうのが異なります。

被害の有無

ただの計算であり悪い動作は無い、という意見がありました。

これに関しては、無罪判決と無った地裁においても、反意図──つまり閲覧者の意図に沿わない動作であることはみとめ「ユーザーに利益をもたらさないものである上、ユーザーに無断でCPUを提供させて利益を得ようとするもの」とばっさりしています。

実際に、本来動かなくて良かったCPUやGPU(CoinhiveはCPUのみですが)等の消費電力増加による電気代金、ファン等の経年劣化加速など積み重なると無視できないと思われる不利益は生じています。決してゼロでは無く、社会通念上許される範囲であるかです(ここは広告等と同じ)。

他にもありますがそれは次に書きます。

カジュアルにCoinhive等が普及した場合

本件は無罪であるべきだ、という主張の上で、ただそれを受けてCoinhiveのようなクライアントリソースを消費するソフトウェアが普及した場合を考えます。

その場合、先ほども書いた通り「消費リソース量が金銭的インセンティブに”比例”する」という点が大きな問題となります。現状では(逮捕者が出たこともあり))数限られたウェブサイトでしか利用されていません。しかしこれが様々なウェブサイトで普通に使われるようになると、自明ですがブラウザの動作が重くなります(小並感)。

それが加速すると、クライアントリソースの取り合いとなり、CPUは常時100%に張り付き、本来CPUを消費するべき重要なアプリケーションの動作が重くなるなど、具体的なユーザの不利益に繋がります。

さらにそれが進んだ結果、ブラウザにクライアントリソースに対する使用量制限(quota)のような仕組みを取り入れることが予想され、煩雑な仕組みといたちごっこにつながります。そしてその結果不利益を受けるのは、普通のウェブアプリケーションです。

法規制とアーキテクチャによる規制

この手の話をする上で重要な視点として、できる限りこういったものは各国の法では無く、アーキテクチャとして解決すべきという意見があります。私も極めて同意します。

ですが本件に関しては、マルウェアと極めて近い領域のユースケースであることが多く、アーキテクチャとして何らかの規制(上記のquotaなど)を設計したとしても、それを回避するような「いたちごっこ」となることが予想できます。

その一方でユーザの意図に沿ったリソースを多く消費したいウェブアプリケーションも存在します。少なくともそれらの間に画期的かつ現実的な解決策が提案されるまで、この問題が野放図になることも、現行の不正指令電磁的記録(コンピュータウイルス)を対象とした法律の拡大解釈で運用されることも望みません。

その落とし所として、リソースの消費にインセンティブがあるようなソフトウェアへの法規制は一定の現実解では無いかと考えています。

まとめ

Coinhiveのようなクライアントリソースの消費量がそのまま金銭的インセンティブに比例するソフトウェアを黙って仕込むことは極めてクソであり、ユーザへの告知無しでは規制されるべき、オプトインが義務付けられるべきものと感じます。

その一方で、それは上記のような性質に対して規制されるべきものであって、現行の不正指令電磁的記録の枠組みでは不十分であり、あらためて法整備すべきです。そして法律の不遡及原則から、本件は無罪となるべきです。

既に逮捕してしまったから、今から法改正を進めると現行法での無罪が確定してしまうので強硬になっているのでは、というコメントすら見かける始末です。法のアップデートが遅いうえに、古い法に基づいて「非倫理的」だと判断された行為を逮捕するために既存法の拡大解釈が行われることは極めて遺憾です。

 

以上、個人の感想でした。

 

新刊:TechReport 2019.12 「2019年振り返りと2020年予想」

あけましておめでとうございます!

昨年末に行われた技術書同人誌博覧会2とコミックマーケット97に、個人サークル「めもおきば」として参加してきました。

gishohaku.dev

www.comiket.co.jp

今回は間隔が2週間ということで、あわせて1冊だけ新刊を出しました。

年末恒例の技術トレンド予想本です。

nekoruri.booth.pm

今回紹介したキーワードです。

  • 「2019年予想」の振り返り
  • デジタルツイン
  • IoTシステムのデザインパターン
  • エッジコンピューティング
  • Stateful FaaS
  • CNCF CloudEventsとEventBridge
  • 認証基盤のクラウドサービス化
  • パスワードの終焉、MFA 2.0
  • 情報システムとゼロトラスト
  • レガシーシステムと2025年の崖
  • ARMとRISC-V

コピー本と言うことで200円とお手軽価格なので、このあたりのキーワードが気になった方はぜひBOOTHからどうぞ。

 

次回のサークル参加は、2/29、3/1の技術書典8です。二日間ともいます!

techbookfest.org

 

「サーバーレス」の次の段階に進むためのキーワード

この記事は、Serverless Advent Calendar 2019の23日目の記事です。

adventar.org

 

Serverlessというキーワードが登場*1して7年、Google App Engine Preview*2から11年、AWS Lambda*3から5年、みなさんサーバーレスしてますか?

FaaS(Function-as-a-Service)を中心としたサーバーレスなシステム開発事例はいよいよ普及フェーズに入ってきたところですが、その一方でステートレス性などプログラミングモデルとしての制約の厳しさなど課題が多くあることも事実です。というわけで、「サーバーレス」という技術ムーブメントで次の段階に進むためのキーワードをいくつか紹介します。

Stateful FaaS

ソフトウェア実行基盤として、プロセス上のメモリやサーバ上のファイルシステム上のデータを永続化しない*4、ステートレスという性質によって、FaaSはクラウド基盤側が「自由に」スケールさせることができ、その結果として消費したCPUやメモリの量によって従量課金されるというのがFaaSの本質的な特徴です。

スケーラブルなソフトウェア実行基盤としては極めて重要なこのステートレス性ですが、プログラミングモデルとしては面倒なことが増えているというのも事実です。そこで、ステートレスなソフトウェア実行基盤の上に、外部のデータストアと連携してプログラミングモデルとしてステートフルなプログラミングモデルを提供しようという仕組みが登場してきています。

最も有名なものがMicrosoft AzureのDurable Functions*5、特にそのEntity Funtions*6ですが、これらはAzure FunctionsというFaaSの上で、Azure Storage*7を組み合わせて実現しています。ほかにも、KnativeとAkka Clusterを組み合わせたCloudstateなどがあります。

このように、FaaSの「今の在り方」にこだわらず、プログラミングモデルとしてどうすべきか、というのがサーバーレス開発の次を考える上で最も重要なことです。

Streaming Processing

FaaSと相性の良いイベントドリブンなアーキテクチャの採用に伴って、これまでビッグデータ分析のような場面が主に想像されていたストリーム処理を、サーバーレス開発でも活用できます。

もともとビッグデータ分析のためのOSSがいくつも開発されてきたためエコシステムとして十分に育っているのが最大の特長です。プログラミングモデルとしてもこなれています。例えば、Apache Flinkを使って、いわゆるワードカウント(英単語ごとの出現回数を数え上げる)をScalaで実装した場合のソースコードです。

val windowCounts = text
  .flatMap { w => w.split("¥¥s") }
  .map { w => WordWithCount(w, 1) }
  .keyBy("word")
  .timeWindow(Time.seconds(5), Time.seconds(1))
  .sum("count")
(省略)
case class WordWithCount(word: String, count: Long)

継続して流れてくるデータストリームに対して、Scala上のDSLとして抽象度の高いソースコードでプログラムを書くことができます。

考え方の基本は、ストリームデータの一つずつに「キー」が存在し(ここでは英単語)、キーごとに状態(ここではこれまでに登場した出現回数)を持って状態をひたすら更新していくというものです。

Cloud 2.0

ちょっと名前には仰々しさがありますが、今年の2月にPaul Johnston氏によって提唱されたキーワード*8です。制約の多いFaaSや、制約しかないDSLのさらに先として、様々なマネージドサービスの活用によってFaaSのような「自分の書いたプログラム」から脱却しようというものです。

複雑なシステムを、ID基盤やMicrosoft GraphのようなAPIの組み合わせに分解し、ワークフローエンジンやBIツールなどで連携させていくことで、従来のようなウェブアプリケーションフレームワークの上でシステムを実現するのでは無く、クラウドサービスを連携させるための設定(これ自体も、極めて制約が強いDSLですが)として実現できることが増えてきました。古くからのキーワードで言うなら、Infrastructure as Codeにおける「Code」の部分を新しい表現にしたものです。

今年はTerraformのDSL(HCL)を大幅に改善したTerraform 0.12の登場に始まり、HCLの癖の強さをそもそもTypeScriptやPythonなどの内部DSLに置き換えることで大幅に改善するPulumiが急速に普及したほか、AWSからもCloudFormationをラップして、やはりTypeScriptやPythonの内部DSLとして記述できるAWS CDKが登場するなど、Cloud 2.0を実現するための下準備が整った年でした。

これは余談ですが、この20年ほどで、プロプライエタリなソフトウェアよりも、コミュニティによるOSSのほうが結果的に良いソフトウェアが生まれやすいという状況になったのはご存知の通りですが、これはある種その「揺り戻し」でもあり「発展」とも言えます。大量の開発者を抱えたメガクラウドと、そこに載っかる大量の利用者からの不具合報告、改善要望があれば、そのクラウドサービスを構成するソフトウェア自体がプロプライエタリであっても十分な品質のサービスが提供されています。その一方で、OSSによって様々なライブラリやミドルウェアが開発され、自分で開発せずOSSミドルウェアを利用するようになったという流れの先にあると言うこともできます。もちろん、クラウドサービスを実現するソフトウェア自体をOSS化する流れもあり、その最大例がKubernetesです。

クラウドサービスの内部で使われているOSSの開発者との軋轢、という問題*9も生じていますが、まず利用者としては自分で書いて運用するべきコードを減らし、少ないコードでやりたい事を実現することを考えていくべきです。

Serverless Spectrum

AWS Lambdaのインパクトが大きかったため、サーバーレスと言えばステートレスな関数型プログラミングという印象が強いですが、実際はここまで紹介したキーワードからも判るとおり様々な実現方法があります。プリズムで分解した虹色のSpecrtum(スペクトル)のように、サーバーレスかどうか1/0ではなく、様々な形態が地続きで存在しています。

インターフェース一つ取っても、AWS Lambdaを代表とする言語内の関数というやり方もあれば、HTTP*10やgRPC*11を使う場合もあります。

サーバーレスにおいて最も重要なことは、クラウドをクラウドらしく活用(Cloud Native)することで、より少ない手数(≒Code量+運用作業量+α)でより大きな価値のあるシステムを構築していこう、そして従量課金を活用してスタートアップ段階のアジリティも高めよう、という継続的な挑戦を続ける気持ちです。

その一方でこれまでのレガシーなシステムの存在や価値は決して無視できるものでは無く、これからその間を埋めるためのものがたくさん登場していくことでしょう。そして「サーバーレス」として表現される対象もまた、より広いスペクトルとなって拡がっていくことでしょう。過去の記事でも書きましたが、言葉の定義にこだわらず、楽しいことを実現するときに考えを整理するための道具、指針ぐらいに捉えていくのが良いと思います。

まとめ

というわけで、4つほどキーワードを紹介しました。

このあたりのキーワードを追いかけていけば、より楽しくサーバーレス業界の動きを捉えられるのではないかなと思います。やっていき!

 

*1:2012年: Why The Future Of Software And Apps Is Serverless - ReadWrite

*2:2008年: Google App Engine Blog: Introducing Google App Engine + our new blog

*3:2014年: Introducing AWS Lambda

*4:プロセスやサーバが再利用され残っている場合もあれば、別のサーバや新しいプロセスに切り替わり消える場合もある

*5:Durable Functions の概要 - Azure | Microsoft Docs

*6:持続エンティティ - Azure Functions | Microsoft Docs

*7:Azure基盤への依存を切り離すためRedisへの対応も進められています。
Durable Redis Provider · Issue #253 · Azure/durabletask

*8:Cloud 2.0: Code is no longer King — Serverless has dethroned it

*9:個人的な立場としては、元となったOSSの開発者に対してそれに見合った利益が支払われるべきという思いが強いです。

*10:KnativeやGoogle Cloud RunはHTTPリクエストがインターフェースとなっているほか、AWS LambdaもCustom RuntimeのインターフェースはHTTPです。

*11:たとえばAzure FunctionsでC#以外を使う場合、Language Workerとの間は最終的にgRPCでやりとりされます。

「サーバーレス」な同人誌を #ServerlessDays で紹介しました

ServerlessDays Tokyo 2019のライトニングトークで、サーバーレスに関連する同人誌を紹介させていただきました。

tokyo.serverlessdays.io

www.slideshare.net

紹介内容はスライドを見ていただくとして、スマホ等でスライドからリンクが飛べないようなのでリンク先の一覧をこちらでも貼っておきます。

技術書典

techbookfest.org

blog.techbookfest.org

次回は2020/02/29~03/01、サークル参加受付は11/5からです!

技術書同人誌博覧会(技書博)

gishohaku.dev

次回は12/14です!

Google App Engine Webアプリ開発入門

castaneai.booth.pm

Knativeの歩き方

toshi0607.booth.pm

Knativeソースコードリーディング入門

toshi0607.booth.pm

PHPでゼロからはじめるAWS Lambda Custom Runtime

morinomiyakono.booth.pm

ほぼPythonだけでサーバーレスアプリを作ろう

https://www.amazon.co.jp/dp/4844398970

Goで学ぶGoogleCloud Functionsの使い方

misoton.booth.pm

Azure Hodgepodge Vol.01

azuremoku2.booth.pm

ゼロから始めるNetlify

nabettu.booth.pm

nextpublishing.jp

俺たちが知りたかったAlexaの話

alexa.booth.pm

雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、理解できる本

authya.booth.pm

OAuth、OAuth認証、OpenID Connectの違いを整理して、理解できる本

authya.booth.pm

Pragmatic Terraform on AWS

kosmos.booth.pm

nekopunch.hatenablog.com

nextpublishing.jp

Microservices architecture よろず本 その三

ota42y.booth.pm

NATSによるPub/Subメッセージング入門

ponzdou.booth.pm

WANTEDLY TECH BOOK 2018#5

www.wantedly.com

あかるいきんようび。 #2 マイクロサービスとその周辺

https://www.amazon.co.jp/dp/B07HYC1HLN

技術書典7に参加しました

9月22日に池袋サンシャインシティで行われた技術書典7に、個人サークル「めもおきば」および合同誌「ssmjp同人部」として参加してきました。

techbookfest.org

 

今回は、技書博で間に合わなかった「FaaSの次」を議論する記事をコピー本で出しました。テーマ的にはこんな感じのキーワードを扱っています。

  • ステートレスの限界
  • 永続化されるべきデータと一時的なステート
  • シャーディングとFaaS
  • ストリーム処理エンジン
  • アクターモデル
  • Akka Streams
  • Durable FunctionsとEntity Functions
  • CloudState
  • 実行の効率

製本版、PDF版ともにBOOTHでの頒布も開始しました。

200円のお手軽価格なので、興味持たれた方はぜひ読んでください。

nekoruri.booth.pm

さて、今回の技術書典7は、初のサンシャイン2フロア構成と言うことでいろいろ課題もあり、たしかに3F配置組としてはいろいろもやもやする所も多かったですが、公式アンケートにも書きますし、今回を生かして次はもっとうまく解決してくれる技術書典運営だと思っているんでここで多くは書きません。

というわけで、次回は第二回技術書同人誌博覧会でお会いしましょう!