エムスリーエンジニアリンググループSREチームの山本です。
私はエムスリーに入社してまだ1年少しなのですが、前職でも似たような職務を担当していました。
その中で、実は「インフラのあり方」には二大潮流が存在し、その中で皆が苦しみもがいているのではないだろうか？と感じました。前職や現職で感じたアレコレをエッセーのように軽い読み物にしますので、SREブログリレー二日目のネタとして書かせてください
なお、文字だけでは書きたいことが足りぬため、私が直々に画伯として挿絵も描いてしまいます。 ちなみに「麻雀に例えたら」と書きましたが、実は私は麻雀のルールをほとんどしりません。某有名麻雀劇画の作者はルールを知らないのに勢いで麻雀を描いたようですし、私もそれでいきたいと思います。
ロン！クラウド無双！！
新しい技術というのはどんどん入ってきます。そして、どれもが魅力的です。
例えば、クラウド一つをとってみても、毎年、いや毎月のように新たな機能が生まれます。どれも採用すれば開発が容易そうであり、管理も楽そう。コストが減って万々歳です。 エンジニアの性でしょうか。そういったものは導入したくなります。
気づけば、AWSなんとか、Googleなんとかといった技術に囲まれます。
一方で、SREというものは「サービスの最後までそれを見守る」という使命を課されており、採用技術が雑多になってくると、すべてを把握する必要が出てきてしまい、疲弊します。
麻雀でいうところの多種の牌を持ち手とすることを強いられたSREからは死者が出かねません。すべてのクラウドのすべての技術に詳しいわけではないのですから。
二種の潮流
既に書いたように「技術には二種類の潮流がある」のではないかと考えております。その二つについて書かせてください。 なお、以下の話はエムスリーの話でも前職の話でもありません。空想上の極端な例を出したものです。
哭きのSRE
一つの極端な話はこれです。この場合は開発エンジニア主導で、サービスごとに好きなように好きな技術で開発します。
これは素敵な話です。出たばかりのサービス、好きな言語、好きなツールを使って開発し、一からサービスを組み立てます。 スモールスタートであれば、こちらの方が高速に開発できることが多いことでしょう。 楽しいでしょうし、エンジニア採用もしやすそうです。
これを「哭きのSRE」と呼びます。(わかっていると思いますが、そんな用語を使っているのはこのブログのみですので、よそに行って使わないでください。)
メンチン型SRE
もう一つの極端な形はこれです。決まった構成、安定した構成を作り、その枠の中で漸進する。 新たなサービスを開発するとしても重厚長大な自社開発ツール群に組み込んでいくことになります。既存の安定した環境内での開発ですので最終的な安定性は担保されますし、統一された構成で管理も容易です。 「いまどきこれっすか…」と、エンジニア採用はしにくいでしょうが、社内での人材流動性に限っては担保されるかもしれません。
こちらは「メンチン型SRE」と呼びます。（例によって独自用語です。）こちらは美しく同一技術で染めにかかります。
いかんせん古い技術が多くなりやすいという欠点はあります。この構成の中でガチガチに固めてしまうと、全く新しい構成を作るのに苦労することになりかねません。
どちらが正しいのか？
極端な例はどちらもよろしくないのはそのとおりでしょうが、業界にもよりそうです。
会社やサービスが一定の規模になってくると、前者(哭き派)から後者(メンチン派)に変わってくる面はあるでしょうし、それ自体は必ずしも悪いことではないと考えます。(私が描いた絵は極端すぎるわけですが、一つの指針を持って管理しようということ自体は否定できないという意味です。)
SREとしての立場と技術選定
SREはサイトの信頼性を上げることを目的としています。その目的だけでいえば、「構成技術が少ないほうが管理が楽」なのは当たり前です。
「SREが楽だったらそれでいいんだ！」などというものでないのは当然で、「サービスを素早くローンチする」「エンジニアに魅力のある技術を採用する」「開発効率を上げる」といったことを満たさずにいることは許されません。 どちらかというと、SREの都合でサービスの枠が定められるというのは本末転倒であるので、基本的にはどのような技術を選定するのかは、開発するエンジニア側に委ねることが妥当そうです。
「シクヨロー♪」は禁止する
とはいえ、勝手に技術選定をされた挙げ句、「ローンチしたからあとの管理はSREさんシクヨロー♪」と言われると、重量のある予備ハードディスクの一撃が開発エンジニアの脳髄を砕く事件が発生してしまうことは避けがたいことです。
技術選定をすること自体はおまかせしても、その管理についてどのように引き受けるか(あるいは引き受けないか)については応相談ということになります。特にクラウドシフトが進むと、管理についても開発チーム側で一定以上担ってもらう方が適切なこともあるため、(SREエンジニアとしては存在意義が減る話でもありますが)管理を引き受けない方が互いにメリットが出てくることがあります。
エムスリーの場合
多数の技術が共存する状態
さて、空想上の企業の話はおいておきます。
我らがエムスリーにおいては多種多様な技術が存在します。JavaもあればPythonもあり、Rubyも存在するかと思えばミドルウェアも多数です。データベースはPostgreSQLやOracle、MySQLといったものが並んでいます。無軌道に何でも導入しているというわけではないとしても、長年サービスを続けているとこのような現象が起きてしまうことになります。
そのため、SREメンバーは常に管理において殺気立っており、ハードディスクの一撃を食らわすべく日々開発者を付け狙っている…などということはありませんのでご安心ください。 とはいえ、各種のツールやミドルウェア、OSが乱立していることで、管理が煩雑であるということは避けがたい事実となっています。 クラウドシフトする中で、「オンプレミスにどれほど力を注ぐべきなのか」という観点もあるため、いつか消えるであろうオンプレ内の技術乱立排除に工数を大きく割くことはできず、この状況は劇的には改善しておりません。
つまりは現状は「哭きのSRE」の状況です。いまさらこれを全部統一して「メンチン型SRE」にすることには大義もメリットもなさそうです。
チームSREの成功
エムスリーでは昨年から特に大々的に「チームSRE」という制度を導入しています。 これは、各開発エンジニアのチームに所属するSREメンバーであり、開発者が兼任することもあります。
これは結局、「哭きのSRE」でも可能な限りうまいこと管理していく手法なのです。(私が言ってるだけですが。)
従来からのSREは「コアSRE」と呼称し、各種サービスの管理を次々と「チームSRE」に委譲しています。例えば、deploy作業、クラウド管理者権限、構成管理変更といったものを「コアSRE」は次々と手放している最中です。 例えば、Apacheのconfigファイルを少し変えてProxy先を変更する作業というものに対して、「コアSRE」は関与しないし、するメリットもありません。基本的に「チームSRE」で巻き取ってもらうことで、連携が強固な開発チーム内でスピーディにタスクが進みます。またクラウドについては、基本的に「チームSRE」にAdministratorを渡して管理する方針となっています。
比較的狭い範囲を担当するSREであるため、新技術も導入しやすく、「OSの種類とDBの種類とミドルウェアの種類が100もあって死にました」なんていうことは起きそうにありません。
では、「コアSRE」は何をするのかということですが、共通で利用されるシステムの作成や管理、オンプレのハードウェアやVM自体の管理、監視といったものを実施しています。例えばですが、オンプレに存在するOracleなどのデータベースは各サービスから利用されますので、その管理を責任を持って実施するのは「コアSRE」となります。 言い方を変えると、サービスごとのリソースの管理を委譲したことで、共通で利用されるシステム(特に重要なシステムも多い)の管理に集中できる状態となったということです。そして、表層にある新技術(クラウドや新規ツール)の管理から引き離されるので、どちらかというと「メンチン型SRE」に近づくことができます。また古い技術を少しづつ捨てて身軽になる業務も行えています。
さらに今後
「コアSRE」と「チームSRE」の区分や今後は流動的な部分もありそうです。
例えば全てがクラウドに移ったら、「コアSRE」のオンプレの仕事はなくなります。「チームSRE」に吸収されるべきかもしれませんし、社内情報システム部門と統合すべきかもしれませんし、新たな任務を見つけるかもしれません。そのあたりはまだわかりませんが、オンプレミスを廃止するまでにはまだ期間が必要そうですし、コスト管理、ネットワーク管理、共通ツール作成などといった重要な仕事は消えることはありません。
We're hiring
エムスリーではSRE エンジニアを大募集中です！少しでも興味を持っていただいた方は是非お声掛けください。 以下ではコア、チーム両方のSREが募集されておりますので、ぜひ御覧ください。
