メインコンテンツまでスキップ

Software Design 202504

ドメイン解体新書 / CDN​

CDN を利用する際、一般的には CNAME レコードでユーザーのリクエストを CDN のドメインに転送する。 CDN はそのドメインに対して、最適なエッジサーバの IP アドレスを A レコードとして動的に返すため、 ユーザーは地理的に近いエッジサーバに接続される。 接続後、オリジンサーバはリクエストの HTTP ヘッダ内の Host 情報をもとに、返すコンテンツを判断する。

CNAMEの具体的な動作はRFC 1034 に記載がある。 https://datatracker.ietf.org/doc/html/rfc1034#section-3.6.2

CNAME RRs cause special action in DNS software.  When a name server
fails to find a desired RR in the resource set associated with the
domain name, it checks to see if the resource set consists of a CNAME
record with a matching class.  If so, the name server includes the CNAME
record in the response and restarts the query at the domain name
specified in the data field of the CNAME record.  The one exception to
this rule is that queries which match the CNAME type are not restarted.

つまり、こういうこと。

  • DNS で A レコードなどを探していて見つからなかったとき、そのドメインに CNAME があれば、それをたどって別の名前に対して再び検索する。
  • ただし、「CNAME レコードそのものを求めるクエリ（タイプが CNAME）」の場合は、再検索せず、CNAME レコードだけを返す。

ルートドメイン（ゾーンアペックス）には CNAME レコードを設定できない。 CNAME を使うと他のレコードが使えなくなり、SOA や NS など必要なレコードも設定できなくなるためである。 この制限を回避する方法として、ALIAS や ANAME レコードがあるが、これらは DNS の標準仕様ではなく、 使えるかどうかは DNS サービスの実装次第である。 ALIAS や ANAME は参照先の IP アドレスを DNS サーバ側で取得し、その IP を直接返す仕組みになっている。

CDN 設定をする時はあらかじめ既存の DNS レコードの TTL を短くしてからやらないと設定ミスった時に死ぬので注意。

ドメイン知識​

ドメイン知識とは、その領域で必要とされる業界特有の知識を指す。 業界ルール、業務プロセス、課題・ニーズ・トレンド、専門用語などがある。

ドメイン知識を持つとできるようになること

  • 要件定義段階
    • 正しい業務理解
    • 適切な業務フローの設計
    • ユーザーとの円滑なコミュニケーション
    • 規制やコンプラの遵守
  • 開発段階
    • 優先度の判断
    • より良い技術提案
    • 不要な機能の排除

ドメイン知識を身につける方法

  • 入門書を読む
  • 専門家に聞く
  • 客との会話を通じて学ぶ (商談・ヒアリングに積極的に参加する)
  • ユーザー向けヘルプページを読む
  • テーブルやモデルの関係性を掴む
  • あえて隣接領域も学ぶ

PdM だけがドメイン知識をもってエンジニアはただの下請け、みたいな分業が本当に正しいのかよく考えろ。

統合テスト・E2E テストの戦略​

テストシナリオとは、イベントと、それらのイベントを受け入れた後のシステムの状態を定義したもの。 シナリオによるテストは強力だがコストが高いので、価値の高いシナリオに限定するとよい。 価値が高いとは、発生頻度が高いこと、もしくは失敗したときの深刻度が高いこと。

残る広範な範囲を荒く検証するために、シナリオ要らずのテストも併用すること。 特に、ランダムなデータを放り込んでエラーがないことだけを検証するファズテストは有効である。 たとえば全てのページをクロールしてエラーがないことを確認するなど。

データベースのリファクタリング​

データベースはアプリよりも長生きであるがゆえ、リファクタリングは重要。 成功のポイントは以下の通り。

  • 一回ごとの変更は極力小さくする
  • アプリケーションとデータベースの責務を分離しておく (別々に作業できるように。DB のビューを使うとか、AP でリポジトリパターン使うとか)
  • 周到にテストする
  • 移行期間を設ける (⚪︎ 月 ⚪︎ 日にこのカラムは削除します、とか)
  • 監視の仕組みを作っておく

MCP / Model Context Protocol​

MCP は、データが存在するシステムと LLM を接続するための仕組み。 Anthropic 社が提唱している。JSON-RPC をベースにしたもの。 LLM(Cursor, Claude Desktop など)がクライアント、MCP がサーバーになる。

サーバーはツール、プロンプト、リソースの一覧をカタログとして公開し、LLM はそれを利用する。

  • ツール
    • LLM が呼び出せる手続き
    • e.g. 「ファイルを削除する」など
  • プロンプト
    • あらかじめ用意されたプロンプトのテンプレ
    • LLM から受け取る引数や LLM への応答を、一定の型にはめたい場合に使う？
  • リソース
    • 取得できるデータ
    • e.g. データベースのレコード、Web 上のコンテンツなど

MCP の利用形態は二つある。

  • Command 形式 / 標準入出力 / STDIO
    • 手元でサクッと使う場合はこちら
  • HTTP サーバー形式
    • 多数のクライアントからアクセスがある場合はこちら