Misc

はじめに 2025/10/20のAWSの大規模障害から、2日目の朝が過ぎ、色々と見えてきました。ITmediaの記事によれば、原因や経緯は以下のように説明されています。 AWSによれば、今回の障害は「リージョンのDynamoDBサービス（注：AWSのデータベースサービス）エンドポイントのDNS解決の問題」が原因だったという。同社は20日午後6時ごろに問題を解決したものの、今度はDynamoDBに依存するEC2インスタンスの起動システムに問題が発生。対応するうちにトラフィックを分散する「Network Load Balancer」にも問題が生じ、再びDynamoDBなど複数サービスに影響したため、EC2インスタンスの起動など一部サービスの操作を一時的に抑制して復旧に当たったとしている。 DNSのSPoF化 とはいえ、この事実はかなりな、ナンセンスさを内包しています。本来、DNSは冗長な権威サーバー群によって提供され、キャッシュも活用されるため、単一のサーバーやソフトウェアがダウンしてもシステム全体は生き残るように設計されています。しかし、AWSの報告は、DynamoDBというクリティカルな内部サービスのDNS解決が、特定の脆弱なコンポーネントに集中し、それが停止することで、誰も住所を見つけられない状態、すなわち　「内部の単一障害点（SPOF）」　になっていたことを示しています。 認証基盤への影響の軽視 DynamoDBの停止は、IAMなど認証基盤の裏側にも影響しました。この認証基盤がDNSに依存していた、あるいはDNSが停止した時のフェイルオーバー（切り替え）の仕組みが不十分だったこともナンセンスです。 AWSは、 「誰がアクセスしているか」 という最も重要な制御システムを、DNSという単一障害のリスクから十分に隔離できていなかったことになります。 復旧時の二次災害（NLBの問題） さらにナンセンスなのは、DNS問題を解決した後、今度はNLB（Network Load Balancer）の設計が、回復したDynamoDBへのリトライ・ストームに耐えきれず、再びサービスに影響を与えた点です。 これは、AWSのエンジニアが 「自社のトラフィック分散機構が、自社のサービスから発生する負荷（リトライ）で崩壊する」 という最悪のシナリオを十分に想定できていなかったことを示唆しています。 秘伝のたれ：文書化されない知識の蔓延 今回のAWS大規模障害、特に 「内部DNSの設計ミス」と「DynamoDBとNLBの連鎖崩壊」という「話にならなすぎる」原因は、巨大なクラウドインフラ内部に「文書化されていない秘伝のたれ（Undocumented Tribal Knowledge）」 が横行していることの、動かぬ証拠です。「秘伝のたれ」とは、特定のエンジニアやチームだけが知っている、システムの機能に不可欠だが公式には文書化されていない知識、調整、あるいは非標準的な設定を指します。 実際に、The Registerの記事に目を覆いたくなるような記述があります。 “It’s always DNS” is a long-standing sysadmin saw, and with good reason: a disproportionate number of outages are at their heart DNS issues. And so today, as AWS is still repairing its downed cloud as this article goes to press, it becomes clear that the culprit is once again DNS. But if you or I know this, AWS certainly does. ...

私が、経験した中でも最低の部類の幻影に遭遇した。 言うまでもなく、2025年1月21日以降はトランプ政権である。しかし、現状、殆どのLLMは2024年前後で歴史が止まっている。しかし、Geminiはどうやら、RAGで最新化するという機能が弱い。そのため、意識的にURIが与えられないと、事実を補正することが出来ない、また、投入される情報もどうやら、Googleとの提携関係などに依存する部分が大きい。 しかし、このように、自信たっぷりに、虚偽の事象を開陳してしまう。 これは、所謂、ハルシネーションの典型的な事例です。 ハルシネーションの原因としては以下のようなものがあります。 情報の不足：モデルが学習データにない情報を推測して補完しようとする。 RAGの限界：適切な情報を取得できない場合、誤った情報がそのまま出力される。 モデルのバイアス：特定のデータソースに依存するため、偏った情報が生成される可能性がある。 今回のは状況として、まず、恐らく、RAGによる情報の最新化が動いていません。恐らく、情報の不足とモデルのバイアスに引きずられた格好です。GeminiはDeep Researchは強力ですが、現時点では、Gemini 2.5 Flashなどではまだ、ハルシネーションがきついようですね。 あと、Geminiでは唐突にロシア語化する問題を確認しています。今のところ、発生はランダムで、前世代のGemini 2.0で頻発しましたが、現行世代のGemini 2.5 Flashでも同様に発生します。この件は、幾つか報告があります。 Geminiの回答にロシア語が混ざる！原因と今すぐできる対処法 Gemini 2.0 がロシア語を混ぜて回答してくる問題 まず、分かっているところを整理すると、特に会話のコンテキストが長くなる、要は会話のキャッチボールが長くなると問題の発生が多くなる。つまり、コンテキスト周りに問題がある可能性がある。さらに、生成されたロシア語っぽい文字列をdeeeplで翻訳すると意味に関しては大きく外れていないようにも見受けられる。 従って、メモリー破壊などのバグによる生成とは考えにくく、プロセスとしては正常動作の可能性が高い。故に、エラーログなどでの調査は不首尾に終わる可能性が高い。 考えられるのはドリフトなどかと思います。あと、状況からして、専門用語などが不具合を起こしているように見受けられるので未知語などの処理、特に埋め込みベクトルの問題が強いように思いました。 まず、学習データの問題の可能性は低いと考えています。理由は、だとすれば初手から表れてもおかしくないからです。むしろ、コンテキストが深くなると発生するということはコンテキストの深化で何らかの異常が発生すると見られます。 現在、Gemma 3で同様の問題が発生するかトライを試みています。新規の更新がありましたら報告します。

はじめに ようこそdotfilesの世界へを参考に、Windows上での環境整備を始めてみた。ツールとしては、gitとCMD Batch、robocopyを使用。ディレクトリ構造としてはいったんこのような構造で。 Backgrounds Icons Scripts dot WindowsTerminal ConsoleZ BackgroundsはWindowsTerminalの壁紙を格納、%USERPROFILE%のPictures\Backgroundsに展開。IconsはWindowsTerminalのアイコンを格納、%USERPROFILE%のPictures\Iconsに展開する。Scriptsは環境の展開用のCMD Batchを格納している。dotには%USERPROFILE%以下に展開される、ドットファイルを格納。ConsoleZとWindowsTerminalはそれぞれ、ConsoleZとWindows Terminalの設定ファイルを格納してる。 現在の、deploy.batはこのような内容。 copy ..\WindowsTerminal\profiles.json %USERPROFILE%\AppData\Local\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\profiles.json copy ..\ConsoleZ\console.xml %USERPROFILE%\AppData\Roaming\Console\console.xml copy ..\dot\.nyagos %USERPROFILE%\.nyagos robocopy ..\Backgrounds %USERPROFILE%\Pictures\Backgrounds /e robocopy ..\Icons %USERPROFILE%\Pictures\Icons /e