こんにちは！マイクです。今日は2024年10月2日、火曜日です。今週も元気に「zenncast」をお届けしますよ！今日はZennでトレンドの記事をいくつかご紹介しますので、お楽しみに！

さて、今日は前回紹介した記事は特にありませんので、さっそく今日の内容をお伝えしますね。

今日紹介する記事は全部で5本です。それでは、最初の記事からいきましょう。

1つ目の記事は、「typeとinterfaceって結局どう使い分ければ良いの？」というタイトルです。

TypeScriptでは、型を定義するためにtypeエイリアスとinterfaceを使いますが、それぞれに特有の利点があります。typeはUnion TypesやMapped Types、Conditional Typesといった、interfaceでは表現できない型を定義できるのが特徴です。エディタでの型定義の中身が展開されやすく、迅速に確認できるのも便利ですね。

一方で、interfaceはextendsを使った型の結合が速く、コンパイルパフォーマンスも良好です。同名のinterfaceが複数あれば自動でマージされるため、型の拡張性が高いという利点もあります。特に、オーバーライド時に互換性エラーを出すため、実装ミスを防ぎやすくなるのが嬉しいですね。

使い分けのポイントとしては、コンパイルパフォーマンスや拡張性を重視する場合にはinterfaceを、特定の型を定義したい場合にはtypeを使うと良いでしょう。最終的には、好みで選ぶことが推奨されていますが、公式ハンドブックではtypeの機能が必要になるまでinterfaceを使うことが勧められています。

。...。...。...。

次は2つ目の記事です。「AWSエンジニアに必要な知識」というタイトルです。

AWSエンジニアになるためには、IT全般の基礎を7割程度把握することが重要です。具体的には、Linux、ネットワーク、DNS、セキュリティ、Docker、IaC（Infrastructure as Code）などの知識が求められます。

まず、Linuxの知識が必要です。EC2インスタンスでの操作には基本的なコマンドやviエディタの使い方が求められます。そして、ネットワークの知識も必須。AWSの設計にはネットワーク設計が不可欠で、VPCやセキュリティグループを理解することが必要です。

次に、DNSの知識。DNSの仕組みを理解し、AWSのRoute53サービスを使いこなせることが求められます。また、セキュリティの知識も忘れてはいけません。暗号化技術やWAF、Firewallの使い方を習得することが重要です。

さらに、Dockerの知識も必要です。コンテナ技術の理解は必須で、基本的なコマンドやDockerfileの記述方法を学ぶ必要があります。そして、IaCの知識。AWSリソースの管理にはCloudFormationやTerraformを使いこなすことが求められます。

これらの知識は、AWSエンジニアとして非常に役立ちます。全てを完全に理解するのは難しいですが、基礎をしっかり学び、必要に応じて新しい技術をキャッチアップする姿勢が大切です。

。...。...。...。

次は3つ目の記事です。「RAGを社内用語に強くするチャンク分割の手法『MoGG』」というタイトルです。

株式会社ナレッジセンスが提案する「MoGG」は、RAG（Retrieval-Augmented Generation）の性能向上に寄与する新たなチャンク分割手法です。特に社内用語が多く含まれる文書において精度を高めることを目的としています。

従来のRAGは固定サイズのチャンク分割を行うため、文書内の用語説明が離れた場所にある場合、情報が取りこぼされる問題がありました。MoGGは、動的に複数のチャンクサイズを使い分け、チャンクをグラフ構造で表現することで、関連情報を包括的に抽出できるようになります。

具体的には、文書を1-2文単位のチャンクに分け、意味的に類似したチャンク同士にエッジを設定してグラフを構築します。ユーザーが質問を入力すると、グラフのホップ数を決定し、指定された範囲の情報を収集してLLM（大規模言語モデル）に渡すという仕組みです。

このアプローチにより、関連するチャンク間の情報結びつきが強化され、RAGの応答精度が向上します。特に、医療分野の質問応答タスクにおいてMoGGは優れた結果を示しています。今後もRAGシステムの構築にあたり、MoGGを含む多様な手法を検討することが推奨されます。

。...。...。...。

4つ目の記事は「DDDで集約を跨いだ情報でロジックを構築するための『getter高階関数パターン』の紹介」です。

ドメイン駆動設計（DDD）において、集約を跨いだ情報を使ったロジック構築の方法が提案されています。集約とは、関連するオブジェクトを一つにまとめ、ビジネスロジックの適用や整合性を維持する単位です。例えば、ECサイトの「注文」集約は複数の「注文明細」を持ちます。

この稿では、別集約の情報を参照して一つの集約を変更する場合に「getter高階関数パターン」を提案しています。必要な情報を取得するための関数を引数として渡す方法で、これによりデータベースへのアクセスを避け、集約間の依存を緩めることができます。

アプリケーション層では、商品の情報を効率的に取得するために、対象商品だけをDBから取得し、高速アクセスを実現します。また、関数型プログラミングの観点から、入力と依存関係を明確に分けることも重要です。

最終的に、getter高階関数パターンは集約間のデータ取得をシンプルにし、ビジネスロジックの保守性を高める手法として有効であることが示されています。

。...。...。...。

最後に5つ目の記事、「N+1問題を解決すりゃいいってもんでもないらしい」についてお話しします。

本記事では、Rails（ActiveRecord）を使用して発生するN+1問題についての実体験が語られています。N+1問題の解決手段として`preload`を用いた結果、ページの読み込み速度が大幅に低下したという驚きの展開が紹介されています。

特定ページで、カメラマンとその撮影したアルバム、写真の情報を取り扱っていたが、事前に`preload`や`eager_load`が行われておらず、N+1問題が発生していました。解決策として`preload`を使い、カメラマンに紐づくアルバムや写真を事前に読み込むようにしました。

しかし、ローカル環境では高速化に成功したものの、本番環境でのリリース後、読み込み時間が3秒から12秒に悪化。調査を進めると、`preload`で多くの子モデル・孫モデルを一度に読み込むことが原因であることがわかりました。

最終的に、N+1問題を解決しつつも、`limit`を設定して取得するレコード数を制限することで、表示時間を12秒から1秒に短縮することに成功しました。この経験から、N+1問題を解決するだけでなく、ボトルネックを正確に把握することの重要性を再認識しました。

さて、今日ご紹介した記事を駆け足でおさらいしましょう！Typeとinterfaceの使い分け、AWSエンジニアに必要な知識、RAGを強くする手法MoGG、DDDでのgetter高階関数パターン、そしてN+1問題の実体験についてお話ししましたね。

次回もお楽しみに！詳しい内容はショーノートに書いてありますので、ぜひチェックしてください。そして、番組の感想もお待ちしています！それでは、またお会いしましょう！