2026-01-25

今日散髪に行ったところ、戻ってきたらシステムが不安定になっていました。結局、鸡哥が同じサービスのターミナルを2つ起動し、互いに競合したことが大きな問題の原因でした。

1. 今日やったこと：

   1. クラスターをNATの背後に移行しようと試みました。もちろん新しいlegionを使用して実行しました。操作は以下の通りです：

      • まずkopsクラスターを修正し、新しいVPCを作成しました。サブネットとして172.21.0.0/24と172.21.1.0/24を使用しました。そしてトラフィック出口用のNATを作成しました。

        当初は10.0で始まるサブネットを使う予定でしたが、AWSがそのCIDRの作成を許可しなかったため、172.21で始まるサブネットに変更しました。ここで注意点があり、clusterリソース内で既存のロードバランサーを対応するVPCに向ける必要があります（元々は暗黙的にデフォルト指定されていましたが、CIDRを追加したため手動で指定する必要がありました）。

      • 次に新しいインスタンスグループを作成し、新しいVPCに向けました。途中、小さなトラブルがありました。新しいIGにS3権限が付与されていなかったため、手動で追加したところ、ノードは正常にクラスターに参加しました。

      • 次のステップは、手動でサービスを新しいIGに移行することです。

      • 最後に既存のIGを廃止しました。

      完了した後、クラスターの出口トラフィックが1つのIPだけになってしまい、IPレート制限を行っているサービスに大きな負荷がかかってしまいました。やむを得ずロールバックし、まずHTTPプロキシの機能を実装してから次のステップに進む必要があります。

   2. マルチエージェントは、Midasの純資産を自動更新するスクリプトの実践に使用されました。Deepseekが時間をかけて書いてくれましたが、私はかなり満足しています。ここに核心的な問題があります。設計の初期段階で誤りに気づかなかった場合、膨大なトークンと時間の浪費が待っています。なぜなら、エージェントの作業はそれほど速くないと感じたからです。

      現在、これらのコーディングエージェントはまだ初期的で、ネットワーク問題などでよく途中でクラッシュして終了します。長期間実行される本格的な作業を任せるには、SLI（サービスレベル指標）がまだ不十分です。これは機会でもあると考えられます。簡単に考えると、これにはソフトウェアエンジニアリングの高可用性などに関する知識が必要です。

2. 考えたこと：

   今日はあまり考えがまとまらず、すべて上記の節にインラインで書きました。

3. 明日の予定：

   1. YuanのHTTPプロキシ機構を設計する。
   2. デプロイ後にクラスターを再度移行する。