最近読んだもの 7
記事
- How is software developed at Amazon? - High Scalability -
- ピザ2枚のチーム・システムから始まり、それを分割していく（顧客のニーズに合わせて）
- チームには目標と必要なリソースが与えられ、それぞれがひとつのスタートアップのように振る舞う。マネジメントは複数のスタートアップをみる取締役のような立ち位置になる
- エンジニアは、開発者、アーキテクト、運用者、テスター、セキュリティスペシャリストとして振る舞うことを期待される
- チームは職能を跨いだメンバーで構成。エンジニア、PM、マーケターなど
- 計画はボトムアップに（各チームが一番ユーザーをわかっている）
- チーム間のコンフリクトはマネジメントの階層構造で調整
- 何もやらないより、リスクを織り込んで何かを出す方を選ぶ。折り込まれたリスクはのちに別のリファクタチームが解消する。スピードを維持する
- そもそもとしてチームが分かれるとコミュニケーションと一貫性は難しい
- 全体方針はトップダウンで、それへの向かい方は各チームで
- ピザ2枚のチーム・システムから始まり、それを分割していく（顧客のニーズに合わせて）
- QUIC at Snapchat - Snap Engineering
- QUIC 導入はかっこいい施策だが、あくまでネットワークのレイテンシーとエラー率の改善活動の一環として位置付けられているのがよい
- プロトコルの変更以外にも
make requests and responses smaller, reduce unnecessary sync, utilize global content distribution partners to bring media close to the people who use itなどやれる事はたくさんある
- プロトコルの変更以外にも
- 導入による改善は、いずれの指標も 95 パーセンタイル以上で 5 ~ 25 % くらい
- この桁感は覚えておくと参考になりそう
- QUIC 導入はかっこいい施策だが、あくまでネットワークのレイテンシーとエラー率の改善活動の一環として位置付けられているのがよい
- Security headers quick reference
- まとまってる
- curl vs Wget
- curl 作者の @bagder による比較
- curl は cat、wget は cp の analogue とするのは確かにすんなり納得できた
curl works more like the traditional Unix cat command, it sends more stuff to stdout, and reads more from stdin in a "everything is a pipe" manner. Wget is more like cp, using the same analogue.
- wget は busybox に入っていて便利というのはすごいそう思う
- curl はもう http/3 もサポートしていてすごい
- Open Source Insights
- 各種ライブラリの依存関係などが確認できるツールらしい
- Google が各種パッケージマネージャの情報をインデックスしているらしい
- Revisiting the Twelve-Factor App Methodology — Coder Society
- 12 factor apps が出てからもう 10 年とは…
- Application Frameworks | July 2021 | Communications of the ACM
- 当たり前のことが書かれているだけに見えた…
動画
- Accelerate networking with HTTP/3 and QUIC - WWDC21 - Videos - Apple Developer
- もうちょい待てば普通に使えるようになるというのがすごい (サーバ側も対応していれば)
- 途中で出てくる通信のモニタリングツールが便利そうで気になった
雑誌
- WEB+DB PRESS Vol.123 | 後藤 ゆき, 古川 陽介, 吉井 健文, 藤原 涼馬, 雑司ヶ谷, 西山 和広, 五十嵐 進士, 佐藤 歩, 櫻庭 祐一, James Van Dyne, うたがわ きき, 牧 大輔, 池田 拓司, 是澤 太志, 関 満徳, はまちや2, 竹原, WEB+DB PRESS編集部 |本 | 通販 | Amazon
- 特集 1 の HTTP/3 入門目当て
- @flano_yuki さん著
- 短い紙面で概要がまとまっていて良かった
- これからキャッチアップするためのスタート地点として
- 特集 1 の HTTP/3 入門目当て
コード
- rs/zerolog: Zero Allocation JSON Logger
Zerolog's API is designed to provide both a great developer experience and stunning performance. Its unique chaining API allows zerolog to write JSON (or CBOR) log events by avoiding allocations and reflection.とのことでunique chaining APIとavoiding allocationsとはどういう感じか気になったので流し読みunique apiに関しては有名な uber の zap で発明された、メソッド呼び出しを chain できる api のこと- chaining 自体は一般的なインタフェースだけど、確かにロギングの api でこのようなものはなかったかもしれない
- 確かにこれは書きやすそう・読みやすそう
- ログへの出力要素の追加やメタデータの設定がスッキリ書ける
- パフォーマンスに関しては sync.Pool を使って確保したメモリを再利用していることと、出力前のログ内容を単なる
[]byteに追記していっている (内部で構造体などで保持していない) のがポイントだった- Event がひとつのログを表すクラス
- ロギングする内容は
buf []byteに保持しているbufは Event インスタンス作成時に pool から取得 しログ出力後 (Event インスタンス利用完了後) に pool に戻しているbufのサイズは 500 byte からスタート する
bufにはログの要素を諸々処理してから append していっている- 例えば
Str()で要素を足すと、必要なエスケープなどを行ったあとに buf に append する - 同じキーを重複して登録できてしまう 仕様はここに由来する
- 例えば
- 以上よりメモリ確保が走るのは次のケース
- pool に確保済みの buf がない場合、新規で確保する
- pool の初期化時に複数確保したりはしていない
- 500 byte を超えるログを作成する場合、buf を延長する
- ロジックは通常の Go の append と同じ
- pool に確保済みの buf がない場合、新規で確保する
- 基本的には json 出力形式のみサポートされているのは今どきでよい
- ちなみに sync.Pool の各要素は ほぼ同じメモリコストにしないとにしないと非効率 らしく、buf が一定以上大きいと pool に戻さない という制御が入っていた
- sync.Pool の実装は見ずにあてずっぽうだけど、でかいバッファが gc されずに確保され続けることにもなり得そうなので、ハードリミットがあるのは安心感がある
- kubernetes-sigs/kustomize: Customization of kubernetes YAML configurations
- k8s の yaml を外側から色々操作できる小粋なツール
- どうやって yaml のパースやその値の操作をやっているのか気になってそこだけさらっと見た
- 自分で頑張っていた
- kustomization.yaml の定義は以下
- yaml のパース、AST 作成、AST 変換などは kyaml という大きなパッケージが担当している