特集

持続可能な拡張とマルチクラウド連携に向けた統合サーバシステムの革新

ITC では、約 10 年にわたり、義塾の主要なオンラインサービスをはじめとする非常に重要なシステムが稼働しているインフラストラクチャを整備してきました。本稿では、これまで 4 年に一度のペースで進めてきた統合サーバシステム（Keio Integrated Server System、以下、KISS）の、2017 年度に実施したリプレースについてご紹介します。

1. リプレースというもの

みなさんは身のまわりの機械について、何年くらい使えたら十分だと感じますか。使用の方法や頻度にもよりますが、家電や個人で使用しているパソコンであれば、5 年から 10 年使えれば十分と感じられる方も多いのではないでしょうか。
　よしあしの議論は置いて、私たちが管理・運用している機器には 10 年を超える「大物」もあります。
　もちろん、物理的に故障しても修理できなかったり、ソフトウェアに不具合があっても修正してもらえなかったりといった点は、家庭の電化製品が部品供給停止などの事由で修理できず、買い替えが必要になることと同じような事情があてはまります。
　実際のところ、設定不備などでシステムやサービスが正常に動作しないのは問題外ですが、システムを入れ替えた後、1-2 年は大きな問題がなく動作していても、導入から 3 年目以降のリプレース時期が近づくと、一部の部品が連鎖的に故障する不具合にはこれまで何度も悩まされてきました。
　以前よりも非常に早く、多くの技術やそれらを搭載した製品が発表されるなかで、数十万人が、安心して、より快適に義塾のサービスを利用できるようにするためには、その時代にあった最新のものを、最適な方法で調達・導入・運用し、数年に一回というルーチンを繰り返すことは必要だったのかもしれません。

2. 革新への軌跡

KISS はそのときどきのトレンドを比較・検討しながらすべての機器を入れ替えるかたちでこれまでリプレースを繰り返していました。（義塾の規模になると、毎回相当なコストをかけて整備されていることは容易にご想像いただけると思います...。）
　2017 年度に実施した KISS3（「3」はバージョンを表しています）でも、様々な製品を 1 年ほど前から調査していましたが、いずれも非常によい製品であったため、コストが機能に比例している状況でした。
　なお、大きな案件を進める際、私たちは次のようなスケジュールで対応することが多く、ここでは KISS3 を例として簡単に説明したいと思います。

2016 年
8月　　検討開始（各社の最新技術、製品、動向調査）
10月　システム構成案をもとにした予算策定用の見積り取得
11月　予算策定と申請

2017 年
3月　提案依頼書作成
4月　指名競争入札実施
5月　塾内承認手続き
6月　構成と移行作業に関する調整
8月　リプレース完了

まず、該当の案件について、やりたいのか、やらなければならないのか、といった動機や事由のようなものがあります。また、時間的な制約や、何よりもコストがどうなるかは非常に重要なポイントです。その他、限られた人的リソースで、管理・運用も担当しなければならず、導入することがゴールではないため、選定・導入したシステムに絶対の自信と責任をもてるよう、何年も先を見据えた検討や調整が必要です。

私たちは KISS3 で次のような内容を実現したいと考えていました。

• 耐障害性の高い仕組み
• 限られた人的リソースで運用できるシンプルな仕組み
• ネットワーク、サーバ、ストレージの物理的な統合
• リプレース時のシステム・サービス停止回避
• 容易なスケールアウトの実施

そして、私たちは「ハイパーコンバージドインフラストラクチャ」（Hyperconverged Infrastructure、以下、HCI）という結論にたどり着きました。

3. ライフサイクルの再考

「HCI」という言葉を初めて耳にする方もいると思うので、ここでは KISS3 で採用した製品のイメージ図を用いながら説明します。

　左側が KISS2 時のイメージです。3-tier 構造と呼ばれ、サーバとストレージ、それらを接続するネットワーク機器で構成されるため、いずれかに不具合が発生してもサービスの提供を継続できるよう、複数の機器で冗長化されています。このため、設置には十分な空きスペースが必要で、コストもかかり、各機器を個別に管理・運用しなければなりませんでした。

　右側が KISS3 のイメージです。採用した機器はサーバとストレージが一体化しつつも、1U（高さ: 44.45mm）という通常のラックマウントサーバと同じ高さになっています。サーバとストレージを接続するネットワーク機器は存在せず、実際には複数の機器で構成して冗長化していますが、設置スペースはリプレース前の半分以下となりました。運用面では、複数の機器をひとつのシステムとして、まとめて管理できるようになり、不具合の原因特定のために様々な機器を調査する必要もなくなりました。

HCI がスペースや管理面でも非常にシンプルになり、効率的な運用を実現できるようになったことはおわかりいただけたと思いますが、私たちは決して自分たちが楽をするためだけに今回の製品や仕組みを採用したわけではありません。
　何よりも重要なのは、システムやサービスが利用者のためにあるということです。10 年前であれば、様々な制約からメンテナンスや不具合で、年に数回、システムが停止するということはいまよりも許容されやすく、そのようなものだと理解を得やすかったかもしれません。しかし、現在、スマートデバイスの普及や潤沢なネットワークの整備によって、利用者のほうがシステム管理者よりも不具合を早期に発見することもめずらしくはありません。システムやネットワークは利用できて当たり前という考えが浸透していることは事実だと思います。また、私たちもそのような暗黙の期待に応えつつ、より安心して快適にご利用いただけるよう、サービスを提供し続けられる仕組みを整備したいと考えています。
　このような課題を解決するための仕組みも HCI では提供されています。先述のとおり、これまでのシステム構成では、一部の機器や部品が故障した際にも、状況によっては、多くのサービスが停止してしまう可能性が高く、また、停止しないよう手動で緊急の対処が必要でした。また、リプレースともなれば、すべての機器を入れ替える必要があり、サービスの提供を継続したまま作業を完了させることは、非常に困難でした。これに対し、HCI では常に複数の機器でサービスが動作するよう設計されていて、何台で構成しているかにもよりますが、たとえば、1-2 台が故障してまったく動作しなくなっても、重要なシステムが停止することも、データが消失することもありません。また、どの程度、各システムに負荷がかかっているかによって、動作する機器を自動的に選択するなど、最適化のための処理が常に動作しています。さらに、システムやサービスが増加し、リソースの逼迫が想定される場合の機器追加（スケールアウト）の際にも、HCI では、非常にシンプルな操作で、サービスを停止することなく、既に動作している環境を効率的に増強することが可能です。
　これらの仕組みを活用すると、数年に一度というリプレースの概念や、スケールアウトに対する考え方は、今後、大きく変わることになります。今回導入した製品のライフサイクルは現状、これまでと同じ 4 年を想定していますが、本稿を執筆している 2018 年夏の時点で、1 台のスケールアウトおよびさらなる仮想化基盤の統合プロジェクトを進めています。たとえば、毎年 1 台のスケールアウトを繰り返すことで、互換性を保ちながら、リソースは年々強化され、かつ、数年後には、大規模なリプレースを検討する必要もなく、時間や費用、人的なリソースを費やさなくてもよくなります。何よりもサービスの停止で利用者のみなさんにご迷惑をおかけすることがなくなるのは最上のメリットです。
　ライフサイクルの再考はまだまだ始まったばかりですが、着実に対応を進めていきたいと思います。

4. 統合...?

ここでは、私たちが運用している仮想化基盤の全体像について、まずは KISS3 のシステム構成概要図を用いながら説明します。

　義塾には複数の広大な敷地をもつキャンパスがあり、KISS は複数のキャンパスに同等の仕組みを導入して運用しています。当初は 1 キャンパスのみで運用していましたが、キャンパスの電気設備法定点検にともなう電力供給停止の問題や、上位ネットワークの不具合によるサービスへの影響、また、首都圏で大規模災害が発生した場合でも一部の重要なサービス提供を継続できるよう、首都圏以外にもシステムを稼働させられる拠点を整備しています。

上述のとおり、不測の事態や不具合に備えた対策はリプレースの度に実施してきましたが、KISS3 では今後各社から提供が予定されている新たな技術や仕組みを見据えて、いつでも対応できるような構成を採用しています。そのひとつが「クラウド」です。
　数年前は得体が知れず、組織外にデータを保管したり、システムやサービスをキャンパス以外の場所で稼働させたりすることには、かなりの嫌悪感や抵抗感をもつひとも多かったと思いますが、この数年で複数のクラウドコラボレーションツールを導入し、提供するようになったことから、利用者もクラウドを非常に身近に感じ、安全で、安心して活用できるものという理解に変わってきたのではないかと思います。
　現在も複数のクラウド事業者が非常にすばらしいサービスを提供していますが、KISS が目指しているのは、利用者への不断のサービス提供です。電源やネットワークに関する問題は先述のとおりですが、管理・運用上、どうしてもキャンパス内（オンプレミス）で運用したほうが効率的なシステムもあります。現状、サービスを停止させずに、クラウドと連携するには、まだ十分な仕組みが提供されていませんが、数か月、数年先には当たり前のようにクラウドを主な稼働環境として、サービスを提供するシステムが運用されているかもしれません。
　数十台あるいは数百台のサーバで運用しなければならなかった多くのシステムが、KISS3 という名のもとに徐々に集約・統合されています。その反面、あるキャンパスの、ある建物の、ある部屋の、あるラックのほんの一部分に設置され、そこでしか動作しなかったサービスが、いまや、地理的にも、物理的にも、複数の場所に分散される可能性があることを考えると、実に興味深いと思います。

5. システムの行方

義塾のシステムやサービスは今後どこにいくのでしょうか。
　管理・運用担当者のひとりである私からこのような疑問を投げかけることに、違和感がある方もいるかもしれません。多くのクラウドでは、リージョンという国や地域を、システムの稼働場所として指定する機能がありますが、クラウドにはそれぞれ特性があり、なかには月に一度メンテナンスを実施することが明示されているものもあります。私たちが複数のキャンパスで KISS3 を運用しているのと同じように、クラウドサービスを提供する事業者は世界中に拠点を整備していて、リージョン内やリージョン間でシステムを冗長化して運用しています。もちろん、複数のリージョンで稼働するよう設定して、1 拠点がメンテナンス中でもサービスの提供を継続することができるようになっています。
　個人や組織の考え方、ポリシーにもよりますが、みなさんはサービスを利用できなくなることと、そのサービスがどこで動いているかよくわからなくても、問題なく快適に利用できることのどちらを選びますか。もちろん、どこかわからないその場所は、十分なセキュリティ対策がなされ、多少の天変地異には耐えられる構造になっていることが大前提ではあります。
　あくまで、私個人の見解にはなりますが、サービスが停止したり、データが消失したりするくらいなら、クラウド、オンプレミスを問わず、どこでもよいので、システムが動いていてほしいと感じます。義塾の場合、今後もすべてのシステムをクラウドのみで稼働させることは難しく、適切ではないと思います。すべてを自動化してクラウドで稼働させるのではなく、ポリシー次第で柔軟な運用を実現できる仕組みは、そう遠くないうちに提供されるのではないかと思います。
　大切なのは、すべてのシステムやサービスには利用者がいること、その点を見失わずに、これからもみなさんの期待を超えていけるよう、KISS の革新に尽力したいと思います。

本稿でご紹介した内容は、メーカー様のサイトで導入事例が公開されています。ぜひ、あわせてご覧ください。
仮想化基盤の最適解として慶應義塾が選んだ Nutanix

（ご参考）IT 関連の用語で不明なものがありましたら、次のサイトをご活用ください。
IT 用語辞典 e-Words