組織が運用するあらゆるアプリケーション、データベース、分析パイプライン、業務システムは、最終的には三つの物理リソース、すなわち演算処理能力、ストレージ容量、ネットワーク帯域に帰着します。インフラとは、それらのリソースをプロビジョニングし、配置し、運用することで、上位の各層がハードウェアをあたかも抽象的で無尽蔵なユーティリティであるかのように振る舞えるようにする分野です。これが十年前より現在においていっそう重要になっているのは、ITランドスケープに課せられる要求が、より大きく、そしてはるかに予測しにくくなったからです。データ量は予算よりも速く増大し、ワークロードはバッチ処理の時代の計画では想定する必要のなかった形で急増します。さらに機械学習と推論のワークロードの到来は、軽量なトランザクション処理に何年もかけて最適化してきた環境に、重く持続的なリソース負荷を再び持ち込みました。

同時に、ITランドスケープそのものが断片化しています。単一で均質な環境を運用している組織はごくわずかです。典型的な姿は、仮想化されたオンプレミスの中核、一つ以上のパブリッククラウドのテナント、いくつかのSaaS依存、そしてしばしばライセンス、レイテンシ、規制上の理由から統合に抵抗するレガシーな物理ハードウェアの組み合わせです。それぞれが独自の運用モデル、独自の障害特性、独自のコスト構造を持ちます。その実務上の帰結として、インフラはもはやデータセンターを運用することではなく、複数の所有と統制の境界をまたいで一貫したランドスケープを運用し、それを利用する人々に対して一つのシステムとして振る舞わせることになりました。

これがなぜ今重要なのかは明快です。インフラを誤ったときのコストは、組織がインフラに依存する度合いと歩調を合わせて上昇してきました。システムが午後の数時間にわたり利用できなくなった小売業や物流業は、午後半日の生産性を失うのではありません。受注を、信頼を、そしてますます規制上の適格性を失うのです。インフラは支援機能から、事業がそもそも運営できるかどうかを左右する決定要因へと移りました。この賭け金の変化こそが、インフラを本物のエンジニアリングの厳密さで扱うことを正当化します。

ハイパーバイザー、クラスタ、ファブリックといった語彙の奥底で、インフラは四つの約束を果たしており、それ以外のすべてはその約束を守るための手段にすぎません。インフラは容量を約束します。すなわち処理が到来したときにリソースが利用可能であること。可用性を約束します。すなわち個々の構成要素が不可避的に故障してもサービスが継続すること。性能を約束します。すなわち処理が予測可能かつ許容できる時間内に完了すること。そして完全性を約束します。すなわちデータが障害と時間を越えて、破損することなく存続すること。これらの約束をそれぞれどのように、いかなるコストで守るのかを説明できない設計は、設計ではありません。それは願望です。

仮想化は、この四つの約束すべてを再定義した技術です。オペレーティングシステムと物理マシンの間にハイパーバイザーを挿入することで、仮想化はワークロードを、それが動作するハードウェアから切り離します。仮想マシンは、移動し、複製し、スナップショットを取り、別の物理ホスト上で再起動できるファイルになります。この分離こそが、現代の容量と可用性を実用的にしています。ワークロードはより少なく、より高い稼働率の物理ホストに統合でき、故障したり過負荷になったりしたハードウェアから、作り直すことなく移行できます。物理ランドスケープは、個別に貴重なサーバーの集まりであることをやめ、互換性のある容量のプールになります。

ハイパーコンバージェンスは、同じ論理をストレージと、ある程度はネットワークにも適用します。専用ファブリックで接続された別個のストレージアレイを維持するのではなく、ハイパーコンバージドインフラ、すなわちHCIは、演算とストレージを同一のノードに集約し、それらを合わせたローカルディスクを単一のソフトウェア定義された耐障害性のプールとして提示します。その魅力は運用上の単純さにあります。ITランドスケープは、段階的に追加できる均質なノードの集まりとなり、ストレージ層は演算層と同じソフトウェア定義された管理を継承します。第一原理としての要点は、仮想化とハイパーコンバージェンスがインフラの約束する内容を変えるわけではない、ということです。それらは、その約束が守られる粒度と経済性を変え、硬直的で個別に設計されたシステムを、全体として一貫して論じることのできるプール化されたソフトウェア定義の容量に置き換えるのです。

三つの潮流が同時にインフラの実務を作り変えており、本物の転換と雑音とを見分ける価値があります。第一は、ソフトウェア定義のあらゆるものの成熟です。演算の仮想化はとうに定着していますが、ストレージとネットワークもそれに続き、現代のランドスケープはますますアレイやスイッチの物理的な配線ではなく、ソフトウェアの抽象を通じて定義され運用されるようになりました。これがハイパーコンバージェンスを大規模に成立させ、インフラを手作業で組み立てるのではなくコードとして記述し、バージョン管理し、再構築することを可能にします。実務上の利点は目新しさではなく再現性です。ソフトウェアで定義されたITランドスケープは、手作業で組み上げられた環境がけっして提供できなかった確信をもってテストし、監査し、再構築できます。

第二の潮流は、クラウドの経済性についてのより冷静な再評価です。過去十年の移行の波は、パブリッククラウドが本質的により安価であるという前提でしばしば正当化されました。弾力的で、変動が激しく、予測困難なワークロードについては、消費した分だけ支払い、めったに訪れないピークに備えたプロビジョニングを避けられるため、たしかにそのとおりであることが多いのです。しかし安定して予測可能な高稼働率のワークロードについては、その計算はしばしば逆に働き、そうしたワークロードを適切に運用されたオンプレミスまたはハイパーコンバージド基盤に回帰させることでコストが大幅に下がると気づいた組織は少なくありません。成熟した立場はクラウドファーストでもオンプレミスファーストでもなく、ワークロードファーストです。各ワークロードの配置は、流行ではなく証拠に基づいて下される経済的かつ技術的な判断なのです。

第三の潮流は、データ集約型およびAI関連のワークロードがITランドスケープに与える圧力です。推論と学習は、しばしばアクセラレータを伴う持続的な演算を、高スループットのストレージと低レイテンシのネットワークとともに要求します。これは、汎用ワークロード向けに最適化された仮想化ランドスケープが吸収するようには設計されていなかった、リソースを大量に消費しレイテンシに敏感な種類の処理を再び持ち込みます。それはストレージ性能、ネットワークファブリックの設計、そしてそうしたワークロードがどこに属すべきかという率直な問いへの新たな注目を促しています。データの重力とコストの理由から、その答えは、素朴なクラウド全依存の姿勢が示唆するよりも、組織自身のデータに近い場所であることがしばしばです。

優れたインフラは、何事も起こらないように設計されています。そしてそれは標語ではなく、具体的な帰結を伴う設計目標です。第一の原則は、単一障害点の排除です。電源、ネットワーク経路、ストレージの複製、演算ホストといった重要なあらゆる層は、一つの構成要素を失ってもサービスを失わないようにできていなければなりません。仮想化クラスタにおいては、一台以上のホストが故障してもすべてのワークロードが他所で再起動できる十分な容量が残るよう、サイジングすることを意味します。この規律は通常N+1またはN+2の余裕として表現されます。すべてのノードが常に利用可能であると仮定する容量計画は、計画ではありません。それは障害の先送りです。

第二の原則は、耐障害性がワークロードの実際の価値に応じて階層化されなければならない、ということです。すべてが同じ保護に値するわけではなく、そうでないふりをすることは、重要でないシステムに金を浪費する一方で、重要なシステムを保護不足のままにします。ここで復旧目標の言葉がその存在意義を得ます。目標復旧時間はサービスがどれだけ速く復旧されなければならないかを表し、目標復旧時点はどれだけのデータ損失が許容できるかを表します。決済システムとプリントサーバーは、両方の尺度の対極に位置し、それぞれのストレージ複製、バックアップの頻度、フェイルオーバー設計はそれに応じて異なるべきです。すべてのワークロードを最も厳格な階層に合わせて設計することは、すべてを最も緩い階層に合わせて設計することと同じくらいエンジニアリングの失敗です。

第三の原則は、観測可能性を後付けではなく第一級の性質として扱うことです。測定できないITランドスケープは確信をもって運用することができません。容量の枯渇、ストレージのレイテンシの緩やかな悪化、ネットワークの飽和は、障害として姿を現すはるか前に、メトリクスのなかに姿を現すからです。演算、ストレージ、ネットワークを横断する包括的なメトリクス、ログ、トレーシングこそが、運用を後手の消火活動から先を見越した保守へと変えるものです。最後の原則は標準化です。均質なノード、一貫した構成、コードとして定義されたインフラは、逸脱しうるものの表面積を減らします。そしてその逸脱こそが、多くの障害の静かな起点です。退屈なインフラとは、標準化され、計測され、障害に備えて潤沢にプロビジョニングされ、それが担うものの実際の価値に見合ったものなのです。

障害モードを理解することは、ベストプラクティスを列挙することよりも有益です。なぜなら、見た目はまったく異なるランドスケープを横断して、同じわずかな種類の過ちが繰り返し起こるからです。静かな容量の枯渇が最も一般的です。ストレージが満杯になり、メモリのオーバーコミットが限界に達し、あるいは仮想化クラスタが、一台のホスト故障をもはや吸収できない点まで負荷を受けます。システムは、そうでなくなる瞬間まで完璧に動作し、そしてその故障が突然であるのは、まさに警告の兆候が誰も見ていないメトリクスのなかにあったからです。その対策は、より多くのハードウェアではなく、正直な余裕の監視と、傾向線を約束として扱う規律です。

相関故障は、冗長性が実際にはないのにあると仮定する過ちです。同じ回路から給電される二つの電源、同じノード上の二つのストレージ複製、あるいはスケジューラが密かに同じ物理ホストに配置した二つの仮想マシンは、書類の上でのみ冗長です。本物の耐障害性は、あるものの複製が独立して故障することを要求し、その独立性を検証する作業は面倒で、見栄えがせず、しばしば省略されます。けっして復元されないバックアップは、これと関連し、痛ましいほど一般的な障害です。バックアップは何年も実行され、健全に見え、そして最悪の瞬間に、不完全であるか、破損しているか、復旧に絶望的なほど時間がかかることが判明します。リハーサルで復元されたことのないバックアップは、安全策ではなく仮説です。

構成の逸脱は、ランドスケープをゆっくりと蝕みます。かつては同一だったホストが、手作業の変更が積み重なるにつれて分岐し、ついにはITランドスケープの挙動をその文書から予測できなくなり、トラブルシューティングは考古学になります。それ自体が危険である複雑さは、より微妙な障害です。抽象化、オーケストレーション、自動化の一層一層は、それぞれ正当な理由で追加されますが、その総体は、いかなる一人も完全には理解できないシステムとなり、層と層の間の相互作用が、どの層も単独では示さない障害を生み出します。これらすべてに通じる教訓は一貫しています。インフラが構成要素の破損によって故障することはめったにありません。構成要素は壊れることが想定され、それを織り込んで設計されるからです。インフラが故障するのは、冗長性、容量、復旧可能性についてのある仮定が、検証されていなかったと判明するからです。

Nashuaはインフラを、売るべき製品のカタログではなく、証拠に根ざしたエンジニアリングの取り組みとして捉えます。出発点は常に評価です。すなわち既存のランドスケープ、そのワークロード、その実際の稼働率、そしてその真の耐障害性要件についての、率直な棚卸しです。インフラの意思決定の多くは、測定された需要ではなく仮定された需要から出発することによって、その端緒から損なわれます。したがって最初の作業は、仮定をデータに置き換えることです。何が真に安定して予測可能で、何が変動が激しく弾力的で、何が規制やレイテンシの制約を負い、そして何が単に惰性で存続しているレガシーなのか。これらの区別が、その後に続くすべての設計判断を決定します。

その基準線から、Nashuaは参照アーキテクチャではなく、その特定のランドスケープに向けて設計します。統合と予測可能性が有利なところでは、それは正直な障害余裕でサイジングされ、ワークロードの価値に見合った階層化された耐障害性を備えた、仮想化またはハイパーコンバージド基盤を意味します。弾力性や到達範囲がパブリッククラウドを有利にするところでは、ワークロードは意図的にそこに配置され、コストモデルは請求書で発見されるのではなく事前に理解されます。オンプレミスかクラウドかという問いは、ワークロードごとに、その経済性とその技術的制約に基づいて答えられます。それがこの問いに答える唯一の弁護できるやり方です。そのすべてを通じて、観測可能性は最初から設計に織り込まれます。測定できないITランドスケープは、組織が依存する水準で運用することができないからです。

デリバリーは意図的に地味です。Nashuaは、逸脱に抵抗する標準化されコードで定義された構成、仮定されるのではなくリハーサルされるバックアップと復旧の取り決め、そして傾向線を約束として扱う容量計画を重んじます。取り組みは引き渡しで終わりません。インフラはその要求が変化する生きたランドスケープであり、Nashuaのモデルは継続的な運用、監視、定期的な再評価の一つです。それによって余裕、耐障害性、コストが、組織とそのワークロードの進化に応じて現実と整合し続けます。

Nashuaがもたらす違いは、単一の技術ではなく、インフラをその上に立つ事業に対する義務を負った一つのシステム全体として考える思考のあり方です。多くのプロバイダーは、ハイパーコンバージドクラスタを設置したり、ワークロードをクラウドに移行したりできます。しかし、どのワークロードがどこに属すべきか、実際にどれだけの障害余裕を抱えているか、そしてバックアップが実際のインシデントとの接触に耐えられるかを、証拠をもって組織に告げられるプロバイダーはより少ないのです。エンジニアリングの厳密さと正直な経済性のその組み合わせを、汎用のテンプレートではなく特定のランドスケープに適用すること、そこに価値が積み上がります。そしてそれこそが、Nashuaのインフラの仕事が、引き渡された当日ではなく、何も問題が起こらない静かな年月にわたって評価される傾向がある理由です。

また、この仕事が何を前提としてよいかを変える、実務上の当然の帰結もあります。ある取り組みが、まだ存在しない能力を必要とするとき、それは調達サイクルやベンダーのロードマップを待つ必要がありません。enterprise platformは、エージェンティック・エンジニアリングを通じて、ほとんどあらゆる機能を速やかに受け入れられるように作られています。必要なものは平易な言葉で記述され、素早く生成されますが、常に確固たるアーキテクチャの原則の内側で、厳格な品質保証のもとで行われます。それによって速度が、一貫性、セキュリティ、統制を犠牲にすることはけっしてありません。その効果は単に便利であるにとどまらず、戦略的です。それは内製か購入かの境界線を動かし、選択肢を安価に保ち、戦略が棚にたまたまあったものに屈するのではなく、アーキテクチャが戦略に従うことを可能にします。

この取り組みを結び合わせるのは、責任の連続性です。よく設計されても不注意に運用されたインフラは、それが回避するために作られたのと同じ障害モードへと後退します。だからこそNashuaは、構築を到達点として扱うのではなく、運用、監視、再評価を通じて関与し続けます。組織は、最良の意味で退屈なITランドスケープ、すなわちコストが予測可能で、設計によって耐障害性を備え、端から端まで観測可能で、それが担うものの実際の価値に見合ったランドスケープを手にします。時間を越えて持続するその静かな信頼性こそが、重要な違いです。なぜならインフラにおいて最高の賛辞とは、誰もそれについて考える理由がなかった、というものだからです。