複雑さについて話しましょう。これも IT コストです。わかりますか？

7Signals は、パブリック クラウドから撤退した後も、パブリック クラウド プロバイダーと同様のテクノロジー スタックを引き続き使用し、K8S を使い続けるべきでした。しかし、彼らは K8S を放棄し、プライベート クラウド仮想マシン + DOCKER に切り替えました。これは、さらに詳しく調査する価値があります。この事件をより深く理解するために、私は早朝にReworkがDavid氏と37SignalsのCOOであるEron Nicholson氏に行ったインタビューの記録を読みました。実際、インタビューからはもっと考える価値のある手がかりが得られるのですが、多くの内容は今日の議論の範囲を超えています。それについては後で話す機会を見つけるつもりです。

このインタビューから、この問題に関する考え方について多くの詳細を知ることができました。 David 氏と彼のチームがクラウドに移行した当初の目的は、IT の複雑さを解決することでした。システムがオンラインになってから 2 週間後には、数十万件のアクセスがピークに達する可能性があります。パブリック クラウドは、この時期をうまく乗り切るのに役立ちました。ビジネスが成熟し拡大するにつれて、システム負荷は非常に安定し、ブラックフライデーに売上が急増したり、クリスマス休暇中に売上が落ち込んだりすることはありません。ビジネスが発展するにつれて、IT システムへの負荷は非常に予測可能になり、パブリック クラウドで解決する必要がある複雑な問題は存在しなくなります。これにより、新たな複雑さが生じます。パブリック クラウドは 37Signals にとってブラック ボックスです。それが本当に安全で信頼できるものかどうかは、問題が発生したときにのみわかります。それ以前は、それは夢のようにつかみどころのないものでした。

37Signals は高額な費用を支払いましたが、それでもより高レベルのサービスを受ける余裕はありませんでした。 Amazon はタイムリーに電話に出ることができず、遭遇した問題はすべて自社の運用チームで解決する必要がありました。そのため、クラウドに移行してから数年経っても、パブリック クラウドは複雑さの問題の解決にはあまり役立たず、運用コストが上昇しただけでした。

自社運用の仮想マシン + DOCKTER への回帰は、複雑さを反映したもう 1 つの例です。彼らは、K8S は複雑すぎると考えており、学習曲線が急峻なので圧倒されていると感じています。すべてが正常に動作しているときは、誰もが K8S は優れていて使いやすいと考えますが、問題が発生すると、解決することができなくなります。登録ユーザーが数十万人いるものの、従業員が 80 名を超える中規模の SAAS サービス プロバイダーにとって、K8S の複雑な操作と保守を習得するのは容易ではありません。そこで、最終的にK8S上のアプリケーションを仮想マシン＋DOCKER環境に戻すことにしました。複雑さが軽減されたことで、システム全体を制御する能力が大幅に向上しました。 12 人以上の運用チームがプラットフォームとシステム全体を簡単に制御できます。これまで、彼らのシステムは常に不必要なシステムの複雑さにさらされており、多くの運用上の課題に直面していました。

大手インターネット企業のビジネスは、膨大かつ不確実な負荷の課題に直面しているため、そのシステムはさまざまな複雑さに直面する可能性があります。そのため、彼らは研究開発から運用まで、この IT インフラストラクチャ プラットフォームとテクノロジー スタックに完全に適合した IT システムを最初から最後まで構築しました。近年では大手インターネット企業も技術輸出を行っており、多くの伝統企業もこうした技術輸出を受け入れています。しかし、これらの伝統的な企業は、外見からしか学ぶことができず、統合を達成できません。そのため、大手インターネット企業の技術を導入した際に、ITの複雑さも導入したが、複雑さの問題を解決する手法を習得することができなかった。同時に、これらの企業の事業はインターネット企業の事業とは全く異なり、解決すべき複雑な問題はそれほど多くありません。実際にこれらの複雑な問題を解決するために鍵を持っている必要はないので、鍵を手に入れてもドアがどこにあるかはわかりません。

実際、多くの企業やチームは複雑さのコストを過小評価し、俊敏性とスケーラビリティの利点を過度に重視しています。ここ数年、私は100万人近いユーザーを対象とする管理システムのプロジェクトを追ってきましたが、そのオンラインユーザー数は最終的には10万人を超えるでしょう。当初の設計では、データベースとして以前の Oracle データベースから RDS Mysql に移行する予定でした。当初は、各データベースが 500 GB を超えない、32C/128 GB の容量を持つ標準 RDS インスタンスを選択しました。研究開発の過程で、彼らはライブラリとテーブルのシャーディングに関する多くの問題を解決し、1年以上を経て、ついにアプリケーションの変革を完了しました。オンライン試験運用フェーズでは、多数のパフォーマンス問題を解決し、データベースをさらに分割しました。しかし、その後、システム全体を立ち上げるには、データベース システムを 120 以上の RDS インスタンスに分割する必要があることがわかりました。そして、処理能力をさらに向上させ、将来的に長期的なシステム運用に備えたい場合には、読み取りと書き込みの分離を採用する必要がありました。この場合、システム全体を 360 以上のインスタンスに分割する必要があるかもしれません。 1 つのシステムでこれほど多くの RDS インスタンスを作成して運用することに不安を感じています。

データベースの複雑さの問題を解決するために、データベース インスタンスの統合を開始し、120 を超えるデータベース インスタンスを大規模な 90C/720GB MYSQL インスタンスに変更しました。これにより、データベース インスタンスの数は 40 以上に減りますが、各データベースの容量は 1.5 TB になります。この新しいデータベース設計を見て、多くの人が安心するようになりましたが、私は新たな疑問も生じました。23C/128GB、500GB未満のMYSQLデータベースインスタンスを運用および保守することは、90C/720GB、1.5TBのMYSQLインスタンスを運用および保守するのと同じくらい難しいのでしょうか? MYSQL を理解し、MYSQL を徹底的に使用したことがある多くの友人は、すでに頭の中に答えを持っていると思います。

長期間稼働する必要があるシステムの場合、複雑さによって必然的に追加コストが発生し、追加コストの額はシステム自体の特性によって異なります。そのため、IT システムの複雑さを解決することは、私が IT 業界で働いてきた 30 年以上にわたって多くの企業が検討してきた課題です。 IOE アーキテクチャは、企業の IT 構築と運用の複雑さを解決することでも大きな成功を収めています。クラウド プラットフォームは、IT の複雑さを解決することで実際に大きな発展を遂げてきました。これにより、ユーザーは、基盤となる IT インフラストラクチャとプラットフォームの複雑さを考慮する必要がなくなり、企業のビジネスに集中できるようになります。

実際、上記の例はそれほど複雑である必要はありません。実際、州全体で約 100 万人のユーザーがこのシステムを使用しています。このシステムは、州ごとに複数のシステムに分割できます。本社の統計分析業務を除き、ユーザーは省をまたいで業務を行うことがないため、各システムのアプリケーションとデータベースは独立して展開でき、統計分析はデータミドルプラットフォームまたはデータウェアハウスで完全に完了できます。

近年、一部の企業の IT は、当初のシンプルな設計を放棄し、より複雑で一見より高度なテクノロジー スタックを選択するという悪循環に陥っているようです。しかし、これらの設計で導入された複雑さは、遅かれ早かれ運用コストという形で現れることになります。複雑さは IT コストの問題でもあり、遅かれ早かれ人々は広い視野で考えるようになるでしょう。