Technology Radar vol.26(2022年03月版)を読む
Technology RadarのMar. 2022を読んだので、気になった項目をまとめて、感想を記録しておく。
今後、詳しく調べたいものは以下の通り。
- Transitional architecture
近々、レガシーシステムを更新するので勉強しておきたい。 - AKHQ
Kafkaが絡んだ障害調査に使えそう。Kafkaって、調査が必要になる頃にはコマンドとか忘れていそうだし。 - Pactflow
コンシューマ駆動テストを導入したい。
その他に気になったものを取り上げる。
Techniques
11. Transitional architecture
Trial
トランジショナル・アーキテクチャは、レガシー・システムを置き換える際に有用な手法である。建物の建設や改修の際に足場が組まれ、再構成され、最終的に撤去されるのと同じように、レガシーシステムを置き換える際には、しばしば暫定的なアーキテクチャが必要になる。暫定的なアーキテクチャは、後で取り除かれるか、置き換えられることになるが、リスクを低減し、困難な問題をより小さなステップに分割できるようにする上で重要な役割を果たすため、単なる捨て作業ではない。なぜなら、より小さな暫定的なステップを最終的なアーキテクチャのビジョンに沿わせることはできないからである。アーキテクチャの 「足場 」が最終的に取り除かれ、後に技術的負債とならないようにするためには、注意が必要である。
感想: 業務でレガシーシステムの置き換えをする予定なので、この辺を意識して作業を進めたい。
Platforms
27. eBPF
Trial
数年前から、Linuxカーネルには拡張Berkeley Packet Filter（eBPF）という、特定のソケットにフィルタをアタッチする機能を提供する仮想マシンが含まれている。しかし、eBPFはパケットフィルタリングをはるかに超えており、ほとんどオーバーヘッドをかけずに、カーネル内のさまざまなポイントでカスタムスクリプトをトリガーすることができる。このテクノロジーは新しいものではないが、オーケストレーションされたコンテナとしてデプロイされるマイクロサービスの利用が増えるにつれて、その本領を発揮しつつある。KubernetesやIstioのようなサービスメッシュ技術が一般的に使われており、制御機能を実装するためにサイドカーを採用している。新しいツール - 特にBumblebeeはeBPFプログラムの構築、実行、配布をより簡単にする - により、eBPFは従来のサイドカーに代わるものと見なすことができる。この分野のツールであるCiliumのメンテナは、サイドカーの終焉を宣言しているほどだ。eBPFをベースにしたアプローチは、サイドカーにつきもののパフォーマンスや運用におけるオーバーヘッドをある程度削減するが、SSLターミネーションのような一般的な機能はサポートしない。
感想: サービスメッシュって、余程複雑なシステム構成でもない限り導入に見合ったメリットがない気がしていたので、ちょっと気になる。
34. VerneMQ
Trial
VerneMQ はオープンソースの高性能分散 MQTT ブローカーです。私たちは過去にMosquittoやEMQのような他のMQTTブローカーを紹介してきました。EMQやRabbitMQと同様に、VerneMQもErlang／OTPをベースにしており、非常にスケーラブルです。低レイテンシーとフォールトトレランスを維持しながら、コモディティハードウェア上で水平方向にも垂直方向にもスケールし、多数の同時パブリッシャーとコンシューマーをサポートします。社内のベンチマークでは、単一のクラスタで数百万の同時接続を達成することができました。これは新しいものではありませんが、私たちは以前から本番環境でこれを使用しており、うまく機能しています。
感想: こういうメッセージブローカーって結局何を使うのがいいのだろう?
43. Temporal
Assess
Temporal は、特にマイクロサービス・アーキテクチャ向けの、長時間実行するワークフローを開発するためのプラットフォームである。Uberの以前のOSSプロジェクトであるCadenceのフォークであり、プロセス／マシンのクラッシュにも耐えられるように、長時間実行するワークフローのためのイベントソースモデルを持っている。マイクロサービス・アーキテクチャで分散トランザクションを使用することはお勧めしないが、もし実装する必要がある場合や長時間実行するSagasが必要な場合は、Temporalに目を向けるとよいだろう。
感想: 分散トランザクションはやりたくないけど、どうしてもって場合はあるだろうな…
Tools
44. tfsec
Adopt
Terraformを使用する私たちのプロジェクトでは、tfsecはすぐに潜在的なセキュリティリスクを検出するためのデフォルトの静的解析ツールになりました。CIパイプラインに統合するのが簡単で、主要なクラウドプロバイダーやKubernetesのようなプラットフォームに対するチェックのライブラリが増え続けている。その使いやすさから、tfsecはどのTerraformプロジェクトにとっても良い追加になると信じている。
感想: セキュリティは難しいから、こういうのがあると便利なのかな。
45. AKHQ
Trial
AKHQは Apache Kafka 用の GUI で、トピック、トピック・データ、コンシューマー・グループなどを管理できる。私たちのチームの中には、AKHQがKafkaクラスタのリアルタイムのステータスを見るための効果的なツールであることを発見した人もいます。例えば、クラスタ上のトピックをブラウズすることができます。各トピックについて、名前、保存されているメッセージ数、使用されているディスクサイズ、最後のレコードの時間、パーティション数、同期中の量とレプリケーション係数、コンシューマーグループを視覚化できます。AvroとProtobufのデシリアライズオプションにより、AKHQはKafka環境におけるデータの流れを理解するのに役立ちます。
感想: Kafkaの状態を調査するのって難しいから、こういうのがあると便利そう。
48. Conftest
Trial
Conftest は、構造化された設定データに対してテストを記述するためのツールです。Open Policy AgentのRego言語に依存しており、Kubernetesのコンフィギュレーション、Tektonのパイプライン定義、あるいはTerraformのプランに対するテストを書くことができる。私たちはConftestとその浅い学習曲線で素晴らしい経験をしてきました。テストからの迅速なフィードバックにより、私たちのチームはKubernetesの設定変更を迅速かつ安全に繰り返しています。
感想: Terrformのテストってどの程度のことができるのだろう。
54. Pactflow
Trial
私たちはPactを受託テストに長く使っており、スケールに伴う複雑さの一端を見てきました。私たちのチームの中には、Pactflowを使ってその摩擦を減らすことに成功したチームもあります。Pactflowは、SaaSと同じ機能を備えたSoftware as a Serviceとしても、オンプレミスのデプロイメントとしても動作し、オープンソースのPact Brokerの上に、使いやすさ、セキュリティ、監査機能が追加されています。また、オープンソースのPact Brokerの上に、使いやすさとセキュリティ、監査機能が追加されています。私たちはこれまでの使用に満足しており、契約テストを大規模に管理するためのオーバーヘッドを取り除く努力を続けていることに満足しています。
感想: コンシューマ駆動契約テストが必要な気がしているが導入できないでいる。これで使えるようになるといいかなあ。
59. Web Test Runner
Trial
Web Test Runner は Modern Web プロジェクトのパッケージであり、ES odules のような Web 標準をサポートするモダン Web 開発のための高品質なツールを提供する。Web Test Runner は、ウェブアプリケーションのためのテストランナーです。既存のテストランナーと比較した場合の利点のひとつは、ブラウザ上でテストを実行できることです（ヘッドレスでも構いません）。Puppeteer、Playwright、Seleniumを含む複数のブラウザ・ランチャーをサポートしており、テスト・フレームワークにはデフォルトでMochaを使用している。テストはかなり高速に実行され、デバッグ時に devtools でブラウザウィンドウを開けるのが気に入っている。Web Test Runnerは内部的にWeb Dev Serverを使用しており、テストスイート用にカスタマイズされたプラグインを追加するための素晴らしいプラグインAPIを活用することができる。最新のWebツールはとても有望な開発者ツールチェーンのようで、すでにいくつかのプロジェクトで使っている。
感想: テストが高速って言うのが良さそう。
Languages and Frameworks
76. Kotest
Trial
Kotest （以前はKotlinTest）はKotlinエコシステム用のスタンドアローンテストツールで、ネイティブ、JVM、JavaScriptなど様々なKotlin実装のチーム内で支持され続けている。主な利点は、テスト・スイートを構造化するために様々なテスト・スタイルを提供することと、エレガントな内部DSLで表現力豊かなテストを可能にする包括的なマッチャーのセットが付属していることです。以前Radarで取り上げたテクニックであるプロパティベースのテストをサポートしていることに加え、我々のチームはIntelliJプラグインとサポートのコミュニティが成長していることを気に入っている。
感想: Kotlinって海外では使われているのだろうか。Kotlinの評価が低いのは日本だけ?
79. Android Gradle plugin - Kotlin DSL
Assess
Android GradleプラグインのKotlin DSLは、GradleビルドスクリプトのGroovyの代替としてKotlinスクリプトのサポートを追加した。GroovyをKotlinに置き換える目的は、IDEでのリファクタリングやシンプルな編集をより良くサポートすることであり、最終的には読みやすく保守しやすいコードを生成することである。すでにKotlinを使っているチームにとっては、慣れ親しんだ言語でビルドに取り組むことにもなる。少なくとも7年前の450行のビルドスクリプトを持つチームが、数日で移行した。大規模または複雑なgradleビルドスクリプ
トを使用している場合、Kotlinスクリプトがチームにとってより良い結果を生むかどうかを評価する価値がある。
感想: やっぱり、みんなGroovyは使いにくいと思っていたんだ…
85. MistQL
Assess
MistQLは、JSONライクな構造に対して計算を実行するための小さなドメイン固有の言語である。MistQLは元々、フロントエンドで機械学習モデルの特徴抽出を手作業で行うために作られたもので、現在はブラウザ用のJavaScript実装と、サーバーサイドのユースケース用のPython実装をサポートしている。MistQLのきれいな関数型シンタックスはとても気に入っており、あなたのニーズに応じて評価することをお勧めします。
感想: Pythonとかでjqを使いたい時に使うのかなpipyのjqパッケージは使いにくそうだし。
88. ShedLock
Assess
分散プロセッサのクラスタにおいて、スケジュールされたタスクを一度だけ実行することは、比較的一般的な要件である。例えば、データのバッチを取り込んだり、通知を送信したり、定期的なクリーンアップを実行したりするような場合です。しかし、これは有名な難問である。遅延や信頼性の低いネットワーク上で、どのようにしてプロセス群が確実に協調するのだろうか？クラスタ全体でアクションを調整するには、何らかのロックメカニズムが必要だ。幸いなことに、様々な分散ストアがロックを実装することができる。ZooKeeperやConsulのようなシステムや、DynamoDBやCouchbaseのようなデータベースは、クラスタ全体のコンセンサスを管理するために必要な基本的なメカニズムを持っている。ShedLockは、独自のスケジュールされたタスクを実装したい場合に、Javaコードでこれらのプロバイダを利用するための小さなライブラリだ。ロックの取得と解放のためのAPIと、様々なロック・プロバイダーへのコネクターを提供する。独自の分散タスクを書いているが、Kubernetesのようなオーケストレーション・プラットフォーム全体の複雑さを引き受けたくないのであれば、ShedLockは一見の価値がある。
感想: Javaを使う事が多いので覚えておこう。
Discussion