この忌々しい戦争
大規模なグローバルWAN展開には、リスクが伴います。その一つが規模ですが、効果的なプロジェクト計画と管理によって対処可能です。もう一つは複雑さですが、設計と非常に効果的で有能なエンジニアチームを組み合わせることで、これも解決可能です。
もちろん、古いプロバイダーの選択を解除して新しいプロバイダーを選択した場合でも、変更は部分的にしか行わず、しばらくの間は古い会社と新しい会社の両方でハイブリッド システムを実行することになるため、古いベンダーに詳細かつ複雑な構成変更を実行してもらう必要があるという潜在的な問題があります。
数年前までは、上記のどれも問題視されていませんでした。移行の第一歩は、米国の4つのサイトを古い環境から新しい環境へ移行するという単一の作業でした。同僚と私は、主要データセンターがある米国東海岸へ飛びました。もう一人の英国人は、中西部にある別のデータセンターへ向かいました。
米国の2つのオフィスには、それぞれ2人の現地IT担当者が配置されていました。作業開始は東部標準時午後7時（母国では真夜中）で、変更作業は約9時間かかる予定でした。準備はすべて完了し、スイッチとルーターの設定はバックアップされ、内蔵フラッシュメモリに新しい設定がコピーされてすぐに使える状態でした。ケーブル類にもラベルが貼られ、新しいベンダーのルーターに交換する準備も整っていました。
仕事は終わった...よね？
そろそろ何か食べる時間だ。東側の私たち二人はデータセンターを出て街へ出て、ファイブガイズのハンバーガーショップを見つけた。良さそうだったので、それぞれアメリカンな小さめのハンバーガー（まあ、そうだけど）を注文した。
その時、電話が鳴った。イギリスの重大インシデントマネージャーからだ。何か変更したか？いいえ、と私たちは言い張った。今、夕食中だから…。しかし、運用に影響するような変更はしていないと確信していたにもかかわらず、どうしても疑念が頭から離れなかった。新しい設定をアップロードしたものの、絶対に、絶対に、公開していなかった。その点は確信していた。それでも、不安に駆られ、データセンターに戻って全てを確認した…ところが、何も変わっていないことに気づいた。
問題は、自宅のネットワーク（ほとんどのシステムが稼働している私たちの活動の中心地）が、世界から断続的にアクセス可能だったことです。ある瞬間はアクセスできたのに、次の瞬間にはpingを無視してしまう、といった状態でした。
重大インシデント発生が宣言され、ホームシステムをマネージドサービスとして提供していた旧ベンダーが原因究明に着手しました。1時間経っても問題は全く分からず、不安定なネットワークでは変更後のテストの失敗が変更によるものか、根本的な問題によるものかを判断するのは不可能だと考え、私は渋々作業を中止しました。
一晩中電話で何時間も費やしたが、ほとんど改善が見られなかったため、私たちは空港へ向かい、帰国の飛行機に乗るまでの間、サービス プロバイダーに問題の解決を任せることにしました。
問題は自宅のファイアウォール（WANとインターネット接続を制御）に関係しているという結論に至りました。ファイアウォールはかなり古く、ソフトウェアのバージョンもそれほど古くはないものの最新ではありませんでした。プロバイダーは新しいファイアウォールを2つ送ってくれると約束してくれました。しかも、ファイアウォールのエキスパートを飛行機に乗せ、段ボール箱いっぱいの機器を同封して送ってくれました。翌日には状況はほぼ改善されたので、安心して元の状態に戻りました。
興味深いことに、ベンダーはラボで古いファイアウォールを稼働させたところ、完璧に動作しました。何の不具合もなく、私たちが経験した問題も再現しませんでした。1ヶ月後、私は米国に戻り、予定通りの作業を完了しましたが、何の問題もありませんでした。（ただし、新しいベンダーのPMが冗談交じりに「テストは99.9%合格したものの、些細なケースが1つ不合格だったので、11時間のロールバックプロセスを実行しなければならないかもしれない」と指摘したところ、「くたばれ」と冗談めかして言われたことはありましたが…まあ、その言葉は当然だったと思います。）
なんて素敵なカップルなんだ
数日後、また奇妙な動作が現れ始めました。アメリカのネットワークとは関係ないはず（そもそも全く新しいものだったので）なので、原因を推測し始めました。以前からお世話になっているベンダー（彼らのエンジニアは私がこれまで一緒に仕事をした中でもトップクラスでした）は、頭を悩ませ、ラボで色々と試していたところ、耐性のあるファイアウォールの片方を止めて、もう片方で作業するという提案をしてくれました。あっという間に、すべて正常に戻りました。うーん。
この発見さえできれば、あとは簡単でした。ファイアウォールは同じデータセンター内に設置されておらず、アクティブ/スタンバイのペアで、各データセンターに1台ずつ設置され、2つのDC間はダークファイバー接続で接続されていました。しかし、何らかの理由で「スプリットブレイン」状態に陥っていました。スタンバイ側の機器がプライマリ側の機器の位置を把握できなくなり、「さあ、今度は私がマスターになるぞ」と言い出すのです。アクティブ/スタンバイ構成で2台のアクティブなファイアウォールが存在するのは、滅多に良いことではありませんが、今回のケースもまさにその通りでした。問題が分かれば、機器の位置を把握し、混乱が生じた場合に強制的にアクティブ/スタンバイ状態に戻すのは簡単でした。
最終的に問題が判明しました。DC間のダークファイバーリンクの片側にあるLANスイッチのファイバーモジュールに障害が発生していたのです。概ね正常に動作していたのですが、1兆分の1%のわずかな時間だけ、ファイアウォールが互いの通信を失ってしまうほどの短時間、通信が途切れてしまうことがありました。
教訓は、耐障害性のあるデバイスペアの接続に複雑さが伴う場合、リスクも伴うということです。通常の構成であれば、ユニットを同じ場所に設置し、その間をLANケーブルで直接接続することで、通常はアップ状態かダウン状態かを判断します。私たちの構成では、ダークファイバー3マイル、ファイバーモジュール2台、LANスイッチ2台を使用していましたが、断続的な問題が発生した場合の挙動は、従来のアプローチに慣れていたエンジニアにとって馴染みのないものでした。
しかし、もう一つ教訓があります。各拠点に人員を派遣するのに多額の費用がかかり、それを断念するには大きな代償が必要でした。断念という決断は当然のことでした。しかし、それでも非常に不安でした。二つ目の教訓は、入手可能な事実と意見に基づいて難しい決断を下すことを恐れないことです。最初は本当に大変ですが、そこから得られる自信は、その後のキャリアの礎となるでしょう。®
