コミュニケーションを軸として幅広い領域に多数の事業を展開するMIXIは、多様なサービスのほぼ全てをマルチクラウドで運用している。その一方で、明確な理由や妥当性がある場合にはオンプレミスも活用することにしており、両者を使い分けているそうだ。

7月23日～24に開催された「TECH+フォーラム - クラウドインフラ 2024 Jul. 理想の環境にアップデートする」に同社 執行役員 CTO 開発本部長の吉野純平氏が登壇。MIXIのインフラの変遷を紹介し、クラウドとオンプレミスをどのように選び、どう課題に対応してきたかを説明した。

  • MIXIにおける各サービスの環境

クラウドを活用しつつ、オンプレミスも併用

吉野氏がMIXIに入社した2008年はオンプレミス全盛期で、同社でもSNSなど2事業をオンプレミスで稼働させていた。吉野氏がそこでまず担当したのが、回線のマルチホーム化だ。その目的は、自社のIPアドレスを持ってインターネットに接続し、回線を自由に切り替えながらサービスを提供するためだったという。ここでBorder Gateway Protocol（BGP）の技術を体験していたことが、後にハイブリッドクラウドにチャレンジする際に役立ったと同氏は話した。

2011年からは、データセンターを削減して拠点を減らすためにパブリッククラウドの利用を開始した。数カ月間に渡って4Gbps程度のデータを24時間書き続けるなどのテストを行った上でクラウドに移行したが、すでにマルチホーム化をしていたため、自社のネットワークとクラウドを直接接続することができ、回線コストを大きく抑えられたという。

MIXIでは「プライベートクラウドをつくらない」という方針を採っているが、実は2013年に一度検討したことがあると吉野氏は明かす。ネイティブアプリを開発する際に、mobile backend as a Service（mBaaS）を活用してモバイルのバックエンドサービスをマイクロサービスで実装しようと試みた。しかし、フロントエンドとmBaaSを同時につくることは難しく、要件の整理と実装も同時に多発する。同氏曰く「すさまじく難しかった」そうだ。

これと並行してOpenStackを使ったセルフサービス化にも取り組んだ。従来、SNSの運用と開発は別組織で権限も別だったが、このときDevOpsを取り入れて両者が連携できるようにした。開発者が自分の案件で権限を持てるようになり、運用者にデプロイを頼む必要もなくなるため、開発者でセルフサービス化を進めていけると考えたそうだ。しかし、常に続いている進化にどう追従していくか、依存している各種ライブラリの不具合にどう対応するかといった課題にも直面したという。

データセンターからの撤退活動で気付いたこと

その一方で、SNSのシステムの集積度を上げる活動も行った。データセンターの使用台数を減らしてコスト削減につなげようという狙いだ。しかし、ストレージ内容の移行が難しい数台があると解約ができず、コスト面の効果が出るまで時間がかかってしまう。そこで、可能なものはパブリッククラウドに移行すべきだと考えるようになったという。

同氏がここまでの経緯の中で気付いたのは、解約できる単位に注意すべきということだ。マルチテナントであれば撤退の効果は最も遅い作業に引っ張られる。したがって、1つの事業の単位で解約できるようになっていなければ、ある事業だけが積極的に撤退を進めても、 トータルでは削減できないためだ。

「1トラック単位など解約できる単位以上の大きさがないものは、オンプレミスでは動かすべきではないと、そのとき考えました」（吉野氏）

さらに吉野氏は、人的リソースは基盤より事業をつくるほうに配分したほうが良いということにも気付いたという。共通の基盤をつくってもニーズが多様で共通解が見つからないことがある。そのため、もしも基盤をつくる場合、必要なところにピンポイントでつくるべきなのだ。そこでMIXIでは、事業ごとに物事を判断できるよう、基盤に依存して事業をつくることを避けているそうだ。

モンスターストライクはクラウドからオンプレミスに移行

従来、多くのサービスをオンプレミスで稼働させていた同社だが、ゲームアプリの「モンスターストライク」は最初からクラウドでスタートさせた。しかしすぐに大ヒットしたためアクセスが増加。それにシステムが耐えられるよう、オンプレミスへの移行を決めた。オンプレミスならIOPSの高いデバイスを使うことができ、データベースの性能を向上できるためだ。

逆に前述のマルチテナントの環境やOpenStackは全廃し、パブリッククラウドに移行した。その際、同じものをクラウド環境に再現するのではなく、マイクロサービスを合体させて各事業のバックエンドに置いた。モノリシックにしておけば、事業ごとに独自進化をした場合でもエンジニアは個別のサービスではなく合体した1つのサービスを見れば良いためである。

クラウドでの稼働は、調査開始から2週間程度で開始できたそうだ。吉野氏自身が経験済みのBGP技術を応用できたことも短期間でできた理由の1つだが、光ケーブルを構内に配線できるよう準備するなど、クラウドの活用を念頭に置いて拠点をつくっていたことも大きいと同氏は説明した。

「来るだろうという未来像を共有して予算化し、それに対してどう仕込んでいくかということが重要だと感じました」（吉野氏）

メンテナンスに頼らず運用できるよう設計

こうした一連の活動の中では、機材の問題への対処も重要だったという。システムが高負荷になるため熱による機材の不具合が出たほか、削減活動を行ったため機材を小さいサイズにリプレイスすることも必要となった。ただ、SNSのみの事業体であれば24時間365日の稼働が前提になるが、ゲームならアップデートやメンテナンスでの休止も挟める。そのため、中断の発生する恐れのある作業も含め、メンテナンスの際にさまざまな対処を行うことができたそうだ。

同社ではメンテナンスをできるだけ短時間でできるようにしているが、その一方でメンテナンスに頼らない運用も目指して工夫している。アーキテクチャの変更により、メンテナンス以外のタイミングで多くの作業を安全にできるようにしてきたのも工夫の1つだ。

オンプレミスでは、サーバのマルチテナントを廃止する変更も行った。複数のシステムが間違えて通信することを防ぐなどの理由で、ネットワークを完全に分離することが目的である。大きな1つのサービスを運営していたインフラのネットワークを、物理的ではなく論理的に分割したわけだが、「これはかなりのレアケースではないか」と同氏は述べた。

クラウドを運用・維持する上での課題とは

ハイブリッドクラウドを運用する上では、まず通信の遅延が課題になる。オンプレミスとクラウド間の通信で往復回数が多くなれば遅延が増幅され、サービス性能に大きく影響を与えてしまう。またパケットロスが発生した場合には、問題点を切り分けてクラウド事業者に説明するのも難しい。さらに、クラウドに期待していた柔軟なリソース確保も大量になると現実的には難しいケースもあり、突発的に負荷が上がった場合には「ひたすらインスタンスをつくったり、APIリクエストをかけたりといった対処に追われた」（吉野氏）こともある。

クラウドでは、回線接続のサービスの料金体系が多種多様であることも悩ましい点だ。ベースが高額だったり、ベースが低価格でも通信量によっては高額になったりとさまざまなパターンがあるので、常用するとなるとユースケースに左右される。スケールに波があるため普段使っていないリソースも使うことがあるが、それがいざというときに信用できるのかという不安もつきまとうし、変動できる在庫量にも限りがある。

こうしたスケールの変化に対応するため、MIXIではオンプレミスを活用することで波を吸収している。クラウド用の設備の一部をオンプレミスに振り分けるほか、可能な場合には電気料金を従量契約にすることで負荷の低い機材の料金を抑えているという。

吉野氏は「今後はどんなアプリであれクラウドでも動くことを目指すべき」だと話す。オンプレミスは現時点ではうまく使えているため、今後も選択肢の1つになるよう進化させていくが、いつでもクラウドに移行できる状態にして、その実績も持っていくことが重要だと考えているそうだ。

「私たちは今後もクラウドを活用していきますが、オンプレミスも必要があればどんどん使っていこうと考えています。どちらかに依存しないことが重要なのです」（吉野氏）