こんにちは。エンジニアのりゅーそうです。

microCMSのエンジニアチームでは、毎週1時間ほど社内勉強会をしています。
有志のメンバーが話題を持ち寄って発表したり、適当にテーマを設けて雑談したり、、、とゆるく数年間運営されています。

今回はそんなmicroCMSの勉強会ではどんなことが話されているのか？11月（全4回）で話した内容を紹介したいと思います。

第1週

データ構造とアルゴリズム

村松さんからデータ構造とアルゴリズムの基礎についての解説がありました。
microCMSのある処理では数十分もの時間がかかってしまっている処理があり、その問題を解決する際にどのようなアルゴリズムを選択したのか実践的な内容も踏まえて話していただきました。
村松さん曰く「データ構造の選び方が重要」「最適化はアルゴリズムを変えることではなく、データの持ち方を変えることから始まる」というのがポイントとのこと。

ある処理では、配列のデータ構造を再帰で重複処理してしまっていたことによってかなりの時間がかかってしまっていたそうです。

• 配列をハッシュマップへとデータの持ち方を変える。
• 隣接リストから逆向き隣接リストへとデータ構造を反転する。

などデータ構造を変えることによってベンチマークがどのくらい向上したのかという結果も共有していて、最適化の考え方が知れてとても興味深かったです。
データ構造やアルゴリズムを知ることで、データや処理の見方がすごい変わることが分かってとても良い発表でした！

Docker outside of Dockerについて

石井さんよりDocker outside of Docker（doodと略されるそうです）についての解説がありました。
microCMSではdevcontainerを活用しており、doodを使って運用されているそうです。
doodではdevcontainerの外でdockerが実行されるので、環境変数を用意して、ホストマシンからみたディレクトリをマウントするなど工夫して運用をしているとのことです。

最近では git worktreeを使用して他のコンテナを実行するケースもあり、その際には git worktreeのディレクトリからもホストマシンをから参照できるようにパスを調整したりという工夫をしているそうです！
このあたりは使っていても全く意識していませんでしたが、インフラ周りも開発フローに合わせて色々調整されていることを再認識できました。

AppSyncの検証について

同じく石井さんよりAppSyncのGraphqlのレスポンスをコンソール上で追加できるツールの紹介がありました。
https://aws.amazon.com/jp/about-aws/whats-new/2020/09/aws-appsync-improves-the-experience-to-query-graphql-apis-in-the-aws-console/
Graphiqlを活用してローカルで実行する方法も！
https://aws.amazon.com/jp/blogs/mobile/appsync-graphiql-local/
これまではバックエンドのローカル開発はデプロイして行っていましたが、ローカルでのホットリロードでの開発の可能性を共有していただきました！

第2週

ローカルでLambdaとAppSyncが起動するようになりました

先週に引き続き石井さんより、ローカルでLambdaとAppSyncを起動するよう実装したという発表です。調査から翌週には改善に繋げているのが素晴らしいです！
GraphQLのsimulatorサーバーはLocalStackでの実行も考えたそうですが、コストや実行回数の制限から独自にコードを実装したとのこと。

Amplifyに @aws-amplify/amplify-appsync-simulator というAppSyncをシュミレート実行するライブラリがあり、それを参考にしたそうです。
またそれぞれの関数を実行するローカルサーバーを追加し、複数Lambdaを実行しているmicroCMSの環境でも起動できるように調整したそうです。
今後はStep FunctionsやDynamoDB Streams、EventBridgeなどにも対応していくそうで期待です！
実際にバックエンドの更新がホットリロードで更新されて、今までのビルドしていた時間は....となっています。意外と手の回っていなかった改善でナイスでした！

iterパッケージについて

Goの1.23で追加された iter パッケージの使い所について村松さんに解説していただきました。

開発者が自作したシーケンスを言語組み込みの for ... range で直接回せるようになり、チャネルと同じ感覚でかけるそうです。
1.23以前はチャネルやスライスに変換しないと range できなかったが、シーケンスを直接 for v := range Seq のように右辺に置けばOKとのこと。
標準スライスと同じ文法で自作シーケンスを消費できるのが大きなメリットだそうです。
ユースケースとしては

• 大規模データのチャンク処理（外部ライブラリの lo.Chunk に依存せず、標準機能と iter だけで遅延チャンク化を表現できる。）
• 標準ライブラリとの連携（maps.Keys, maps.Values, slices.Values などが iter.Seq / Seq2 を返すため、標準 API だけで「range 可能なシーケンス」を生成できる。）
• CSV/ファイルストリーム処理

などを挙げていました。
またmicroCMSの既存コードの適用例として全データをチャンク化して取得している処理ではメモリの節約につながるというメリットがあるそうです。
標準のiterパッケージによって外部ユーティリティの依存が減るというメリットがあることがよくわかりました！

第3週

Goのjson/v2のomitzeroを試してみた

寺田さんによるGoのjson/v2で採用されるomitzeroについての発表です。
検証の内容はZennのスクラップにもまとめているそうです。
https://zenn.dev/aiiro/scraps/fb0266a424b766
社内ではomitzeroとomitemptyの挙動の違いについてデモも交えながら、紹介していました。
主に
[omitzero]
Goのゼロ値に基づいてフィールドを省略するかどうかを判断する。
例えば boolのfalseやintの0、stringの""などはGoのゼロ値のため省略されるそうです。
またniilスライスはゼロ値として扱われるため省略される
[omitempty]
JSONとしての「空」の概念に基づいて省略するかどうかを判断する
例えばboolのfalseはJSONとして「空」ではないため省略されないという挙動の違いがあるそうです。

公式ドキュメントにもこのあたりの違いが明記されていますが、実際にデモで値がどう変わるのかを比較しながら見れてとても勉強になりました。

OpenTelemetryについて

三由さんによるOpenTelemetryについての発表です。
プラットフォームエンジニアの業務でGrafanaなどを扱う際にオブザーバビリティについての知識を体系的に知りたくて今回OpenTelemetryについてまとめたそうです！
OpenTelemetryの概念などをまとめていただきました！
OpenTelemetryにはログ・メトリクス・トレースの要素があること。
アーキテクチャとして

• Instrumentation Libraries
• OpenTelemetry API/SDK
• Exporter
• Collector（このプロキシにテレメトリーデータを送ると中で処理されて、バックエンドにエクスポートされる。受け取ったテレメトリーデータの成形やフィルタリングなどを行う役割があるそうです）
• Backend（Grafanaなど）

があり、特にmicroCMSではCollectorが実装されていないとのことだったので、Collectorについての解説があり仕組みが知れてとても勉強になりました。

GitHub (security)Advisory DatabaseとDependabot Alerts

宇都宮さんによる発表です。https://github.com/advisories についての解説をしていただきました。
リポジトリのDependabot Alertで脆弱性の報告があったパッケージについては、自動で更新用のPRが作られます。しかし、機械的にパッケージのバージョンが解決できないような場合は、自動でPRは作られないそうです。
そういった場合は手動で解決してあげる必要があるとのことで、Cursorコマンドを用意して自動でPRを作成できるようにしたとのことです。

/inspect-security-patch GHSA-xxxx-xxxx-xxxx 
/inspect-security-patch GHSA-xxxx-xxxx-xxxx [パス]

microCMSでは全エンジニアにCursorが付与されていますが、このようにCursorコマンドで実行できるのはとても良い仕組みだと思いました！

第4週

AppSync Eventsについて: 現在進行中の「コンテンツ編集中メンバーの表示」と今後他のイベントの拡張についてまとめました

千葉さんによるAppSync Eventsについての解説です。
コンテンツ編集中のメンバーアイコンを表示するという機能開発をしている中でリアルタイム通信の要件が必要となりAppSync Eventsを採用したそうです。
主な特徴として

• チャンネルベース（SubscribeとPublishによる特定のチャネルの購読と送信）
• 認証・認可（Cognito User Poolsによる認証とLambda統合によるアプリケーション側での細かい認証が可能）

といった特徴を挙げていました。
その中で実際のmicroCMSのコードではどこでSubscribeをして、どこでPublishをしているのか？というシステム構成を共有していただきました。認証用のLambdaなどをどのようなフローで実行しているか？などの構成がとてもわかりやすかったです。

microCMSでは人数も増え、機能追加が並行で進んでいくようになりました。段々と把握できない実装も増えていきがちなのでこのような共有はチームとしてもありがたいですね。

json/v2はストリーミング処理ができるから、Marshal, UnMarshalしたときに元のJSONの並び順を再現できるようになったし、パフォーマンスも良くなったという話

寺田さんよりタイトル通りですが、json/v2についての解説がありました。
今回はGoのjson/v2でMarshal, UnMarshalした時のJSONの並び順をスライスに格納していくことでキーの並び順を再現できるようになったそうです。
以下にサンプルが掲載されているとのことです。
https://cs.opensource.google/go/go/+/refs/tags/go1.25.4:src/encoding/json/v2/exampleorderedobjecttest.go

microCMSではコンテンツAPIレスポンスやWebhookなど並び順も含めて厳密な値を返す必要があり、このあたりをどのようにGoで実現していくかは課題でした。そのあたりも含めてどのようにすれば並び順を担保できるのかデモも含めて紹介いただきとてもわかりやすかったです。
寺田さんはGoの言語仕様について毎回デモ付きで実践されていて、手を動かしながらキャッチアップしているんだなというのが素晴らしいですね。見習いたいところです。


11月は以上です。今月も大変勉強になりました。自分は発表できなかったので12月は頑張りたいと思います。