Zenn
🤖

Technology Radar 2024年04月版を読む

2024/12/21に公開
Technology Radar
tech

Technology RadarのApr. 2024を読んだので、気になった項目をまとめて、感想を記録しておく。多くは、LLMを始めとした生成AI関連だった。

今後調べたいものは以下。

  • CloudEvents
  • Karpenter

7. テキストからSQLへの変換(試行)

自然言語での問い合わせを、SQLに変換できる技術。「Vanna」という、オープンソースのPython製リトリーバル強化生成（RAG）フレームワークがある。

感想: ある程度、スキーマに対するSQLを学習させないといけない。自分一人で学習させて、利用するだけならあんまりメリットはなさそう(最初からSQLを書いた方が早い)。SQLを書けないセールス部門やマネジメントの人に、学習後に利用させるのには使えるかもしれない。ただし、答えが正しいのか検証する必要があるとなると使ってもらえない可能性の方が高い。

11. LLMバックエンドによるChatOps(評価)

エンジニアは自然言語を使ってソフトウェアの構築、デプロイ、運用を行うことが可能になる。「PromptOps」と「Kubiya」がその初期例として挙げられる。ただし、プロダクション環境に導入する場合には高度な注意が必要。

感想: ChatOpsそのものが不要と、最近は思っている。余計なレイヤー(変換処理)を入れると保守工数が増えるだけ。最初は物珍しくて使ってみたけど、CDサーバからボタンをクリックして実行する方が、圧倒的に何をしているか把握しやすい。

13. 生成AIを活用したレガシーコードベースの理解(評価)

レガシーコードベースの理解にGenAIを活用する製品や技術が次々と登場しています。「Driver AI」や「bloop」は、言語インテリジェンスとコード検索をLLMと組み合わせたリトリーバル強化生成（RAG）アプローチを採用し、ユーザーがコードベースを効率的に探索できるように支援する。

感想: 一度、規模の大きなオープンソースのリポジトリのコードを読んでみたいが、トライアルが面倒くさそう。

15. 幅広い統合テストについて(保留)

Martin FowlerのBlikiエントリで定義されている、実行時のすべての依存関係のライブバージョンを必要とするテストを幅広い統合テストとする。このようなテストは、必要なインフラ、データ、サービスを含む完全なテスト環境が必要であるため、コストが高くつく。リリースサイクルを遅らせる傾向がある。信頼性とリリース頻度のバランスを取ること。このバランスを取るためには、以下の2段階で実施する方法が有効。

  1. テスト対象システムの動作を検証する
    実行時依存関係から一定の応答が得られることを仮定し、サービス仮想化を使用して依存関係のテストダブルを作成する。この方法により、テストデータ管理の懸念が軽減され、決定論的なテストが可能になる。

  2. 環境の仮定を検証する
    実際の依存関係を使用して環境の仮定を検証する契約テストを実施する。

感想: まあ、そうだよね。

19. CloudEvents(採用)

CloudEventsは、サービス、プラットフォーム、システム間の相互運用性を提供するために、イベントデータを共通のフォーマットで記述するための仕様。CloudEventsは現在、Cloud Native Computing Foundation（CNCF）によってホストされており、卒業プロジェクトとして認定。

感想: 採用になっているから、仕様を読んで、SpringでJava SDKを使ってみたい。Kafka Protocol Bindingとの組合せも気になる。

20. クラウドでのArm(試行)

Java VM上で動くサービスやリレーショナル・データベースまでが、ビルドスクリプトを変更するだけでArmインスタンスで動くようになっている。また、コストメリットもでているので、Armをデフォルトとしてアプリケーションやシステムも増えている。

感想: 会社の業務でも試す価値があるのかな。

24. インフラオーケストレーションプラットフォーム(試行)

インフラコードの配信やデプロイのワークフローを標準化・製品化することを目指したインフラオーケストレーションプラットフォームが登場。TerragruntやTerraspaceといったビルドツール、Terraform CloudやPulumi CloudなどのIaCツールベンダーによるサービス、さらにenv0やSpaceliftのようなツールに依存しないプラットフォームやサービス。

GitOps、継続的デリバリー（Continuous Delivery）、コードとしてのコンプライアンス（Compliance as Code）など、さまざまなワークフローを可能に。

36. IcePanel(評価)

IcePanelは、C4モデルを活用したコラボレーション型のアーキテクチャモデリングおよびダイアグラム作成ツール。技術者やビジネス関係者が、それぞれ必要とする技術的な詳細レベルまでズームインしてアーキテクチャを理解できる。一方で、コードとしてダイアグラムを管理するニーズが高い場合には、Structurizrが代替として適している可能性がある。

感想: Structurizrの方が気になる。

41. WebTransport(評価)

WebTransportは、HTTP/3の上に構築されたプロトコルで、サーバーとアプリ間の双方向通信を提供。このプロトコルは、従来のWebSocketsよりも多くの利点を持ち、以下の特徴がある：

  1. 高速な接続と低レイテンシ
    HTTP/3を基盤としているため、接続の確立が迅速で遅延が少ない。
  2. 信頼性のある順序付きデータと順序付け不要データの両方をサポート
    UDPのような順序付け不要データにも対応可能。
  3. 複数ストリームの同時処理
    同一接続内で複数のストリームを処理し、ヘッドオブラインブロッキングを回避。

socket.ioなどの人気ライブラリがWebTransportへの対応を進めている。

感想: まだWebSocketすら仕事で使った事もないのに、次が出始めているのか。

43. ZITADEL(評価)

ZITADELは、オープンソースのアイデンティティおよびユーザー管理ツールであり、Keycloakの代替として注目。

B2Bアプリケーション向けのセキュアでスケーラブルな認証システム構築に適している：

  1. 軽量性
    Golangで記述されており、軽量で高性能。
  2. 柔軟なデプロイオプション
    クラウド、オンプレミス、ハイブリッド環境に対応し、多様なニーズに応えます。
  3. マルチテナント対応
    複数のテナントを効率的に管理可能。
  4. 高度なセキュリティ機能
    多要素認証（MFA）や監査ログといった組み込みのセキュリティ機能を提供。
  5. 開発時間の短縮
    設定や管理が簡単で、ユーザー認証関連の開発負担を軽減。

感想: Keycloakも学習コストが高そうだから、設定や管理が簡単ってところに惹かれる。

46. Karpenter(採用)

Karpenterは、Kubernetesクラスタでノードの自動スケーリングを管理するための、よりスマートなオープンソースのKubernetesオペレーター。

感想: 仕事でも使い始めているし、習得しておかないと。

47. 42Crunch API Conformance Scan(試行)

42Crunch API Conformance Scanは、APIのドキュメントに記載された動作と実際の実装との間の不一致を特定するための動的テストツール。OpenAPI形式で定義されたAPIの仕様を基に、期待される機能や応答を比較。

感想: Lintツール程度には期待できそう。

69. Codium AI(評価)

Codium AIは、AIを活用してテスト生成に特化したアシスタントツール。

以下の特徴：

  1. 幅広い言語サポート
    すべてのプログラミング言語で動作しますが、JavaScriptやPythonなどの主要な技術スタックに対する高度なサポートを提供。
  2. 自然言語でのシナリオ提示
    テストコードを直接生成するのではなく、まず自然言語でシナリオのリストを提示。これにより、開発者はシナリオを論理的に検討し、必要なものを選んでテストコードに変換できます。
  3. テスト生成のカスタマイズ
    特定のコードベースやユースケースに合わせて、例示的なテストや一般的な指示をAIに提供することで、生成されるテストの精度を向上可能。

感想: 自然言語でのシナリオ提示ってのが気になる。自動テストのコードを書くのは面倒だし。GitHub Copilotもある程度は生成してくれるが、シナリオ的なもの(最初のきっかけ)を考えるのは人間だから…

79. OpenTofu(評価)

OpenTofuは、Terraformのフォークとして登場したオープンソースツール。HashiCorpによるライセンス変更への対応として開発された。

感想: まだ評価なんだ。HashiCorpの、同業他社を潰すために最初はタダにするダンピングは、昔のMicrosoftを思い出すから使いたいけど。

93. Electric(評価)

Electricは、モバイルおよびウェブアプリケーション向けのローカルファースト同期フレームワーク。

主な特徴:

  1. ローカルファーストアプローチ
    • アプリケーションコードが直接ローカルの埋め込みデータベース（SQLite）とやり取り。
    • データはバックグラウンドで中央データベース（PostgreSQL）と同期。
  2. アクティブ-アクティブデータベースレプリケーション
    • 複数のデータベース間で同時に読み書きが可能で、データの一貫性を維持。
  3. CRDTによるコンフリクト解消
    • 電子的フレームワークはCRDT（Conflict-free Replicated Data Types）の技術を活用し、データの競合を自動的に処理。
  4. エンハンストユーザー体験
    • オフライン環境でもアプリケーションがシームレスに動作。
    • 同期遅延の影響を最小化。

懸念点:

  • 複雑性の増加
    ローカルと中央データベースの統合や同期により、設計が複雑になる場合があります。
  • 学習コスト
    CRDTやアクティブ-アクティブレプリケーションに精通していないチームには、初期の学習コストが発生。

感想: Yjs(https://yjs.dev/)と比較してどうなのだろう。バックエンドにPostgreSQLを使えるのは魅力的。結局、CRDTは難しいってことか。

100. Rust for UI(評価)

既存のRustスキルを活かしてWebやクロスプラットフォームのアプリを開発したい場合、LeptosやDioxusなどのフレームワークを試す価値がある。

感想: RustでGUIが欲しい場合はどうするの？って思っていたから、やっと出揃ってきたか。

103. WGPU(評価)

wgpuは、Rustで開発されたグラフィックスライブラリで、WebGPU APIに基づいている。

感想: Rustネタが多い。

105. LangChain(保留)

近年では以下の理由から慎重な取り扱いが求められている：

  1. 使いにくさと過剰な複雑性
    • 豊富な機能を提供する一方で、API設計が冗長で一貫性に欠けることがあり、学習コストが高い。
    • 概念やパターンの変更が頻繁で、追従が難しい。
  2. 内部動作の不透明性
    • フレームワークが抽象化を多用しているため、開発者がLLMの動作やパターンを正確に把握・制御するのが困難。
  3. 他の選択肢の存在
    • Semantic KernelやHaystack、LiteLLMなど、シンプルで特定のユースケースに焦点を当てた代替フレームワークが利用可能。
  4. 特殊なフレームワークの必要性が低い場合も
    • 特定のユースケースでは、LangChainのような特化フレームワークを使用せずに最小限の実装で十分な結果が得られる場合も多い。

感想: 確かに使いにくそうだった…

GitHubで編集を提案

Discussion