インフラ運用管理共通ツールセット「gi」のこれまでとこれから

IT 基盤部の廣瀬です。

IT 基盤部ではグループ横断で使っている、インフラの運用管理を支援する共通ツールセットがあります。今回は、このツールセットが生まれた背景、存在意義、メリット・デメリット、今までの反省と今後について話します。

gi とは

IT 基盤部には 5 つのグループがあり、弊社で手がけているサービスのほとんどを IT 基盤部の各グループで担当して運用管理しています。

ゲームを始め、ヘルスケア事業、ソーシャル LIVE 事業、スポーツ事業など、多岐にわたるサービスが存在しています。

インフラの運用管理にあたり、それを補助、支援するスクリプトというのはどうしても必要になってきますが、このような状況で、各グループ、各サービス担当チームで各々スクリプトを実装するのはさまざまなデメリットがあるため、IT 基盤部では共通のツールセットをみんなでメンテナンスして使っています。

この共通ツールセットのことを、部内では「gi」と呼んでいます。

gi が生まれた背景

私が入社した 2011 年ごろは、今ほどサービスのバリエーションは多くなく、主軸はゲーム事業でした。

ゲーム事業の開発には内製の MobaSiF と呼ばれる WAF を使っていたのですが、インフラが使うスクリプト群もこの MobaSiF のリポジトリに含まれていました。また、使用している内製のライブラリや、たとえば冗長性の担保といったさまざまなしくみの実装も、ゲームとインフラとで強く結合し、不可分な状態でした。

ソーシャルゲーム勃興期の Mobage のような、急激に成長するサービスを切り盛りするには、このようなモノリシックな構成は一番効率がよいと個人的には思っています。しかし時を経るにつれ、たとえばインフラ側でモジュールを追加したりモジュールのバージョンアップをしようとしても、密結合しているゲームへの影響が怖くて実施できないといった、スピード感が損なわれるケースが散見されるようになってきました。

ちょうどそのような時期に、海外向けのサービスをオンプレではなくクラウドで行うため、インフラ環境をゼロから作る必要がある案件があったり、Perl ではない言語で (MobaSiF は Perl ベースです) サービスを開発する案件が持ち上がりつつありました。

そこでこれを契機に、次のことを実現するために新しいインフラの共通ツールセットを開発しようということになりました。

サービスとは独立した、インフラの運用管理のためのツールセット
オンプレだけでなくクラウドにも対応

設計と初期の実装は私が行ったのですが、加えて次の点も意識しました。

今後、ゲーム以外のさまざまな新規案件が立ち上がるのを見越して、どんなサービスでも対応できる柔軟性を持たせる
将来的な既存案件のスムーズな移行のために、サービス側でも使っているモジュールやサーバ管理のしくみは互換性を維持する

git log をみたところ最初の commit は 2012-11-12 でした。

初期の実装こそ私が主に行っていましたが、これまで延べ 100 人以上の committer による 45,000 近い commit 、今では IT 基盤部が担当するほぼすべてのサーバで gi は導入されており、gi は IT 基盤部みんなで作り上げたツールセットに成長しています。

共通ツールセットのメリット

質の向上

特に監視や構築スクリプトが顕著ですが、各グループにはそれぞれのノウハウが蓄積されています。

それを持ち寄り共通のスクリプトに実装することで、IT 基盤部全体、ひいては弊社のサービス全体の質の高い安定運用への貢献、また運用作業の効率化が実現できます。

学習コストを低く抑えられる

IT 基盤部ではグループ間の異動がたびたびあります。

もし、グループ間で運用スクリプトがバラバラだったら、たとえば、用途やタグによってサーバを検索するような日常的に使うスクリプトの使い方が全然違っていたら、あるいは、同じミドルウェアなのに構築、運用、監視のスクリプトがまったく異なっていたら、異動後にキャッチアップするまでに時間がかかってしまうでしょう。

ツールセットを共通化することで、こういった時間を最小限にカットできます。

また、異なるグループの人どうしの会話でも、 gi が共通言語になるのでやりとりもスムーズになります。スクリプトの名前を挙げれば、どのグループの人でも何を目的としてどのような動作をするものか頭に浮かぶからです。個人的にはこれがかなり大きなメリットじゃないかと思っています。

共通ツールセットのデメリット

一方でデメリットがまったくないわけではありません。

新規メンバーの学習コストが高い

学習コストについてはメリットの節で挙げたような利点がある一方で、新規メンバーにとっては、膨大な数のスクリプト、さまざまな運用管理のしくみなどをひとつひとつ理解していくのは気が遠くなる作業に感じられるでしょう。

新規メンバーにはメンターがついて OJT で学んでもらっていますが、段階的に学べる教材を用意するのは課題としてあります。

ガラパゴス化の懸念

今ならもっと効率がよかったり信頼性が高かったりするツールやシステムが存在するにもかかわらず、なかなか外に目が向かず、時代遅れの内製実装を使い続ける懸念があります。

導入・移行コストはかかるものの、しっかり見極めてよいものは貪欲に採用していきたいところではあります。

修正に対する気後れ

gi が大きくなった副作用か、「gi はこういうものだ」という現在の状態を絶対視しがちな傾向があるようで、便利なオプションのアイデアを思いついても実装しようとしなかったり、「gi が対応していないからあのミドルウェアは導入できない」といったような話をたまに耳にします。

また、コードの修正が他グループへ影響するのを懸念して亜流が生まれてしまっています。たとえば、ディスクの残量を監視する Nagios プラグインのスクリプトは、対応デバイスが微妙に異なるのが複数存在してしまっています。

これらは、たとえばレビューの強制といったシステム的な手法で改善できるものもありますが、gi の根幹の設計思想やガイドライン、gi はみんなで作り上げるみんなのものだよ、といったことを IT 基盤部のメンバーに伝え続けることが何より足りなかったなと反省しています。

新しい gi

既報のとおり、現在、弊社はオンプレからクラウドへ大規模な移行作業を行っている最中です。

そしてこれを機に、これまでの改善点や反省点を踏まえ、gi とその周辺のインフラ運用管理のための内製のミドルウェアを再設計して実装している真っ最中です。

クラウド移行が落ち着いたら、新 gi とその周辺の話もまた別の機会にできるんじゃないかと思います。