こんにちは。サイボウズ株式会社 生産性向上チームの平木場です。
僕たち生産性向上チームは毎週水曜日に Productivity Weekly という「1 週間の間に発見された開発者の生産性向上に関するネタを共有する会」を社内で開催しています。
本記事はその時のネタをまとめたものです。
2023-01-25 号から、基本的に隔週で連載することとしました。たまに単独でも投稿するかもしれません。
今週は 2023-10-18 単独号です。
今回が第 129 回目です。過去の記事はこちら。
news 📺
GitHub Repository Custom Properties Beta - The GitHub Blog
GitHub において、Organization の Admin はリポジトリにカスタムプロパティを追加できるようになりました。
Repository Rules や Required workflow と組み合わせて特定のプロパティをつけたリポジトリのみを対象にルール設定することがやりやすくなりそうです。
現状は動的に Repository Rules を適用するくらいしか使い道がありませんが、今後は GitHub 上での検索などでも使えるようになる予定とのことです。
あらゆる場面で活躍できそうですね。
本項の執筆者: @korosuke613
Requiring workflows with Repository Rules is generally available - The GitHub Blog
GitHub において、Repository Rules 上での required workflows が GA になりました。
required workflows に関しては GitHub Actions – Support for organization-wide required workflows public beta、GitHub Actions - Required workflows improvements | GitHub Changelog の紹介記事を参考ください。
Repository Rules へ移動した件は GitHub Actions: Required Workflows will move to Repository Rules - The GitHub Blog を参考ください。
GA になったことで仕様が安定して使いやすくなったと思います。ライセンスチェックなどの必ず動かしたいワークフローがある場合や、リポジトリの write 権限を持つ人に触られたくないワークフローを強制したい場合などに使っていけると思います。
先ほど出てきた Custom Properties と組み合わせると柔軟にルールを強制出来るので、うまい具合に使っていきましょう。
本項の執筆者: @korosuke613
Repository Rules - Public Beta - History, Import, Export - The GitHub Blog
GitHub において、Repository Rules を JSON で import/export できるようになりました。また、変更履歴が見られるようになりました。JSON の diff も出せます（それぞれ public beta）。
import/export により、ルールセットを共有・再利用しやすくなりました。また、変更履歴がわかるようになりガバナンス的にも使いやすくなりました。
ちなみに、GitHub が github/ruleset-recipes というルールセットのサンプル集を公開しています。Repository Rules どういうふうに使えばいいかわからんという人は参考にしましょう。そのままインポートもできるよ！
本項の執筆者: @korosuke613
CloudWatch launches out-of-the-box alarm recommendations for AWS services
Amazon CloudWatch において、AWS サービスのメトリクスに対して推奨されるアラームを提示してくれる機能が追加されました。公式ドキュメントはこちらです。
CloudWatch コンソール -> すべてのメトリクスを開くと「アラームに関する推奨事項」というスイッチボタンがあります。これをオンにすると、推奨するアラームが存在するサービスの一覧が表示され、推奨アラームを確認できます。
アラームに関する推奨事項では、アラームの内容と、しきい値やパラメータの正当性の理由が表示されます。
さらに、CloudFormation や AWS CLI, Terraform のリソース定義を提示してくれます。以下は Lambda に対する推奨アラームを Terraform で出力した例です。
ユーザーはアクションをどうするかだけを考えれば良いようなテンプレートとなっているので非常に助かります。
resource "aws_cloudwatch_metric_alarm" "cloudwatch_alarm" {
# Missing fields : "Threshold"
# Intent : "このアラームは、関数の同時実行数がアカウントのリージョンレベルの同時実行クォータに近づいていないかどうかをプロアクティブに検出し、それに基づいて対応できるようにします。アカウントのリージョンレベルの同時実行クォータに達すると、関数はスロットリングされます。"
# Threshold Justification : "リージョンのアカウント用に設定されている同時実行クォータの約 90% になるようにしきい値を設定します。デフォルトでは、あるリージョンにおいて、アカウントの同時実行クォータは、すべての機能で 1,000 です。ただし、アカウントのクォータを確認し、AWS サポートに問い合わせて引き上げを依頼できます。"
alarm_name = "AWS/Lambda ConcurrentExecutions FunctionName=sample"
alarm_description = "このアラームは、関数の同時実行数が、アカウントのリージョンレベルの同時実行制限に近づいているかどうかをモニタリングするのに役立ちます。同時実行数の上限に達すると、関数のスロットリングが開始されます。次のアクションを実行してスロットリングを回避できます。1) このリージョンの AWS サポートに同時実行数の引き上げをリクエストする。2) 関数におけるパフォーマンスの問題を特定し、処理速度を上げて、スループットを改善する。3) 関数の各呼び出しによってより多くのメッセージが処理されるように、関数のバッチサイズを大きくする。"
actions_enabled = false
ok_actions = []
alarm_actions = []
insufficient_data_actions = []
metric_name = "ConcurrentExecutions"
namespace = "AWS/Lambda"
statistic = "Maximum"
period = 60
dimensions = {
FunctionName = "sample"
}
evaluation_periods = 10
datapoints_to_alarm = 10
threshold = REPLACE_ME
comparison_operator = "GreaterThanThreshold"
treat_missing_data = "missing"
}
アラームの推奨設定を調べる手間とリソース作成の手間を大幅に削減できる便利アップデートかと思います。
本項の執筆者: @r4mimu
Announcing AWS Lambda’s support for Internet Protocol Version 6 (IPv6) for outbound connections in VPC
VPC を利用する AWS Lambda が IPv6 のアウトバウンド通信をサポートしました。
この機能により、Lambda 関数は VPC 内のリソースに対して IPv6 を使ってアウトバウンド接続が可能になります。
これは、VPC 内で利用可能な IPv4 アドレスが限られている場合にも、スケールできるようになるという利点があります。
また、トランスレーションメカニズム（例：NAT）の必要性が減少し、それによりコストも削減できるとされています。
クラスメソッドさんのこちらの記事では動作検証をしているので、興味がある方は参考にしてみてください。
本項の執筆者: @r4mimu
Amazon EC2 now supports setting AMIs to a disabled state
Amazon EC2 の Amazon Machine Images (AMIs) で AMI を disable（無効）設定可能になりました。
AMI を無効にすると以下のような挙動になります。
- AMI の状態が「disabled」に変更される
- 削除されるわけではない
- disabled にされた AMI は共有できない
- AMI が公開されていたり以前に共有されていた場合、その AMI はプライベートにされる
- EC2 コンソール内でインスタンスを起動する際に、disabled にされた AMI は選択できない
- インスタンスを起動するウィザードや、起動テンプレートを作成する際には表示されない
- 起動テンプレートや Auto Scaling Group などの起動サービスは、disabled にされた AMI を参照し続けることができる
- しかし、そのような AMI からのインスタンス起動は失敗するため、利用可能な AMI を参照するように更新することを推奨
- AMI が disabled される前に起動された EC2 インスタンスには影響がなく、停止、起動、再起動が可能
AMI は re-enable にすると、再び利用できるようになります。
脆弱性の見つかった AMI やパブリックに公開していたが、利用を停止したい AMI などに利用できそうですね。
ちなみにこのポストでは AMI を「アーミィ」と発音すると書かれていました。AWS の人でも「アミ」と「エーエムアイ」派が居そうです。
本項の執筆者: @r4mimu
Docker、ビルドを40倍高速にする次世代のDocker Buildを開発中。DockerCon 23 － Publickey
DockerCon 23 のキーノートで Docker Build が 40 倍（！）高速化されるという発表がありました。
どのようにして 40 倍も高速化される予定なのか興味があったので DockerCon のサイトで登録してキーノートのオンデマンド配信も見てみましたが、Publickey さんの記事のスクショ以上に詳しい情報はありませんでした。具体的な話は続報待ちです。
自分の推測としては、クラウド上でビルドを実行することでキャッシュがチーム間で共有されることと、クラウド上に x86 と Arm のマシンが両方とも使えるので自分のマシンとは異なるアーキテクチャのイメージをビルドするのに QEMU によるエミュレーションが不要になることで高速化が見込めるのかなと予想しています。docker buidx build の裏で動いている buildkit には既にリモートマシンでビルドさせる機能は存在するので、そのためのリモートマシンを Docker 社が公式に提供してくれるようになるのかもしれませんね。
もし自分の予想通りだとすれば https://depot.dev/ が既に似たようなサービスを提供しているようです。 docker build の高速化に興味がある方は試してみるといいかもしれません。
本項の執筆者: @Kesin11
know-how 🎓
ソースコードのハッシュ値を利用したCIの高速化 - Cybozu Inside Out | サイボウズエンジニアのブログ
ファイルのハッシュ値と依存関係のリストを管理するツールを利用し、結果が変わらないジョブを自動的にスキップさせて不要な CI 実行時間を削減する取り組みの紹介記事です。
Bazel, Gradle, Turborepo などのビルドツールには元々このような機能が存在しているため正しく設定すればビルドやテストはスキップ（厳密にはキャッシュから前回の結果を取り出すことで完了させる）できるのですが、この記事のアプローチはビルドツールとは別にソースコードハッシュ値計算ツールの sver を用いて同様の仕組みを外付けで用意することによって実現したようです。
仕組みの構築は少し大変な印象でしたが、上手く使えれば CI の実行時間をかなり削減できそうですね。
本項の執筆者: @Kesin11
AWS Lambdaの高速なコンテナロードの仕組み | CyberAgent Developers Blog
AWS Lambda の内部実装や裏側で行われている最適化の話を解説している記事で、On-demand Container Loading in AWS Lambda という論文の解説をしています。
いかにして高速に無駄なくコンテナロードを行うかという課題に対して、以下の主要技術に沿った解決案の解説が行われています。
- オンデマンドな読み込み、Copy-on-Write (CoW)
- 収束暗号化
- イレイジャーコーディング
キャッシュの話というより分散ストレージの実装やアルゴリズムに近い話でした。自分は上記の技術については知らなかったので、解説を読んで勉強になりました。
直接的に Lambda の運用に活かせるわけではないですが、クラウドサービスの裏側でどのようなことが行われているのかを知るのは面白いですね。
本項の執筆者: @r4mimu
Measuring Git performance with OpenTelemetry - The GitHub Blog
巨大なリポジトリで git のコマンド内部のどこに時間がかかっているかを OpenTelemetry の分散トレーシングを利用して分析したという内容です。
前半は巨大リポジトリにおける問題と git から OpenTelemetry Collector にデータを流す方法について、中盤はたくさんのエンジニアから収集した分散トレーシングデータを分析した際の注意点、最後にこれまで git が巨大リポジトリをうまく扱うために追加してきた数々の機能と他社事例のブログが紹介されています。
個人的には、最後に巨大リポジトリ向けの各オプションとリンク先がインデックスとして優秀なのと、巨大リポジトリを扱っている他社事例が紹介されておりここだけでも見る価値があると思いました。引用したいと思います。
- Create various dashboards to summarize the data and track it over time.
- Consider the use of various Git performance features, such as: Scalar, Sparse Checkout, Sparse Index, Partial Clone, FSMonitor, and Commit Graph.
- Consider adding a Git Bundle Server to your network.
- Use git maintenance to keep your repositories healthy and efficient.
- Consider enabling parallel checkout on your large repositories.
You might also see what other large organizations are saying:
本項の執筆者: @Kesin11
開発生産性、上から見るか 下から見るか / development productivity and cognitive science - Speaker Deck
SmartHR さんによる、プロダクト規模と開発チームが肥大化（複雑化）するにつれて増大する認知負荷に対してどうアプローチするかというお話です。
認知負荷の説明・分類を前半で行い、後半では、それらを減らすためにどのようにアプローチしたかを説明してくれてます。ボトムアップ、トップダウンそれぞれのアプローチ例が示されています。
Four Keys が課題外在性負荷の指標として役立つのでは？という話もあり、Weekly では言われてみればそうかもという意見が出ていました。Findy Team+ のようなツールで定量的にデータを取ることで課題が見えてくるというのは、定量的にデータを取ることはやはり重要かという気分になりました。
個人的には特に認知不可とは何かを認知科学の観点から説明してくれているのが勉強になってよかったです。僕もよく認知負荷が...高い！ということを口ずさんだりしますが、実際ちゃんと知ってた訳ではないので、覚えておきたくなりました。
ていうか紹介されているプログラマー脳読みたくなってきました。
本項の執筆者: @korosuke613
あとがき
今週号でした。最近寒くなったと思ったらなんか日差しは強くて暑かったりしますね（？）
そろそろ今年も終わりそうで戦々恐々としています。
サイボウズの生産性向上チームでは社内エンジニアの開発生産性を上げるための活動を行なっています。そんな生産性向上チームが気になる方は下のリンクをクリック！
State of DevOps Report 2023 のまとめ
そういえば、前回の Weekly で State of DevOps Report 2023 を紹介してくれた @r4mimu さんが、レポートのまとめを別途記事に書いてくれました。Weekly の内容よりもさらに深掘りされているので、興味持った方は読んでみてください。
早く日本語版出てほしいはある
Discussion