インフラ管理の課題
冨田進氏（以下、冨田）：商用に近づくにつれてチームが大きくなり、さらにプロジェクト自体も、当初は4名ぐらいだったプロジェクトが、いまは70名。10倍以上に膨れ上がっています。
となると、やはり苦労した点としては、インフラが問題となってきました。というのもインフラのエンジニアがすごく潤沢にいるわけでもなく、すごく少ないメンバーで回していかなければいけません。
プロジェクトごとにインフラはきちっと用意してあげなくてはいけなくて、「じゃあ、少ない人数で保守・運用可能なインフラってどうすればいいのかな？」という課題が出てきます。
さらに、スクラムの特徴なのかもしれませんが、次々とお客さんの要求が変わるとか、市場が変わることがあります。その場合にインフラも引きずられて、構成変更が必要になることもあり、変更に素早く対応できるインフラも必要です。
元々アプリケーション開発がメインということもあって、アプリケーションのエンジニアが多いんです。新しいメンバーがインフラに詳しいかというと、やはりそこまで全部知っている人というのはなかなか多くなくて。
メンバーが意識しなくても、アプリケーションの開発に専念できる環境づくりが必要で、「なるべく中身を意識しなくてもいいインフラをどう作っていくか？」というのが課題としてありました。
我々はどうしたか？ 3つ、主にポイントがあります。1つ目は、極力インフラをコード化しておく。そうすることで、なるべく手動で作業をするということをなくし、構築ミスをなくす。AWSを使っているんですけども、中身を意識しなくてもうまく使えるようなかたちにしておく。
2つ目は、横展開も可能なインフラのテンプレート化。これは今回のmobi-Crewsの話だけではなくて、組織全体の話になるんですが、プロジェクトがいくつも出てくるときに、インフラもすぐ作りたい。でも、いろんなパターンがあると、その都度「コード化したけど書き換えなきゃいけない」「変更しないといけない」とすごく大変なので、「インフラの基本パターンはこれ」とテンプレート化しておいて、それを横展開していくことで素早くしていきたいと考えています。
3つ目は、これは構築というよりも運用・保守の観点からなんですが、自分たちでサーバーのソフトウェアを管理してると、管理工数がかかってきます。
あとは障害に強い事も大事です。商用サービスに耐えられるインフラを作るというのはすごく大変で、極力マネージドサービスを使用して、運用・保守の負担も考慮するというのがポイントとしてありました。
インフラ構成のポイント
インフラの構成は先ほど説明があったんですけど、Terraformというサードパーティーのツールを使いました。
これは、AWSを使っているときの構成を定義できるツールです。
何がうれしいかというと、1コマンドでインフラがパッとできます。作るだけならおそらく30分もかからない。
さらに、インフラの構成をパターン化しました。大きな考え方としては、大規模なシステムや、「社内のデモで少し動かしてみたいんですけど」などいろいろな要望に合わせて、その構成を大規模向け、小規模向けみたいなかたちで分けています。だいたいいまの状態だと、6パターンしか用意していないです。
構成を限定することで、要はどのプロジェクトであっても、だいたいの構成は「あ、こんなものね」というのをみんなわかっているので、問題のある場所の切り分けとかがすごく簡単になりました。そして、調査時間を短縮することができました。
あとは、構成がある程度の人にわかっているので、「とりあえずインフラは大丈夫そうだね。じゃあ、アプリでいこう」という切り分けもスムーズになりました。別に宣伝ではないんですけど。アプリケーションのデプロイにElastic Beanstalk、ロードバランサーであるとか、サーバであるとかを全部管理してくれるようなAWSのサービスがあるんですが、それを使うことで、開発者はアプリケーションの開発に専念できるし、さらにインフラを見ている人は、構成管理の手間も減る。
そして、障害発生時にも、もともと自動復旧させる仕組みがElastic Beanstalkに用意されているので、さらに障害にも強いと。非常にお得な感じになりました。
商用リリースにあたっての3つの課題
（スライドの）次のページで、「どんな感じの構成になっていますか？」というのを、少し写真に出しました。
これは、クラウドを使った構成をしたときの基本的なパターンと言えるのかなと。真ん中のところにElastic Beanstalkがいて、Web側がいて、ワーカーがいて、クラウドフロントがいて、データベースがいて、というかたちになっています。
大規模であればこのフルフルの構成なんですが、ちょっとしたデモであれば、例えばワーカーを立ち上げずに対応していく、というのがパターンになります。
じゃあ、次は具体的にどういう技術を使っているのか。少し洗い出してみたんですが、「意外と多くないな」という印象を受けました。ある程度いろんなサービスがあって、AWSには100以上あるんですが、使っているのは10もいかない……ある程度少なめでやっています。
いろいろなサービスが出てくるんですけど、僕たちが大事にしているのは、もしなにか新しいサービスを使いたいとなったときにも、「本当に必要なのかな？」「それってなんでいるんだっけ？」というのを議論して、使うサービスを限定しています。あまりサービスを使いすぎると、運用・保守が大変になってくるのです。
さて、商用リリースのフェーズに近づいてくると、また新たな問題が出てきました。
1つは監視。2つ目は性能ですね。とくにデータ量が増えてくるので、「遅くならないよね？」とか、「データ量が増えても、きちっとアプリケーション動きますよね？ 落ちませんよね？」という課題が出てきました。さらに、昨今いろいろ問題になることが多いセキュリティなんですけど、「大事な情報を守れますか？」という点も意識する必要があります。
先ほど挙げた3つの課題というのは、1つのチームのプロジェクトの話では閉じない話で、全体が抱える問題だと思いました。なので、プロジェクト横断の別チーム、僕らSRE、Site Reliability Engineeringチームと呼ぶ、横断の別チームを結成しました。
「じゃあ、その人たちに必要なスキルって何かな？」と考えたときに、開発経験を持っている人がほしいでしょう。さらに検証、テストみたいなのもできる人もほしい。それから、実際に商用のシステムを運用した経験があるメンバーもほしいと。それぞれのスキルセットを考慮したうえで、そのSREが持っているようなチーム構成にしました。
それで、やっていることは忘れがちなのが先ほど挙げた3点だと思うんですけど、そういった点も拾って対策をしていくと。
機能開発に注力しすぎて、上の監視や性能やセキュリティのところがけっこう漏れがちだったりするので、横断的にやっていきます。
あとは、ノウハウを横展開。プロジェクトを横断で見ていると情報がたまりやすいので、そういうものを教えてあげたり、アドバイスしたり、ということをしています。
これらの対応をした問題の例なんですが、監視であれば、システムを監視したうえで、必要なメトリクスを洗い出して横展開をして、次に同じようなプロジェクトがあったときに、「あらかじめこんな監視が必要だよね。じゃあ、監視のほうはこうやって実装しましたよね」ということを展開すると、時間短縮。
また、性能評価用の環境というのを用意して、定期的に性能測定をしています。遅い部分に関しては、アプリケーションのソースコードまで見て、改善して、再評価して。それで具体的に「これでどれぐらい改善したよ」という値まで示したうえで、「じゃあ、ちょっとこれ取り込んでくださいね」みたいなプルリクを送っています。
セキュリティに関しては、自分たちだけで完全にできるものでもなかったので、外部機関と連携し、セキュリティ評価をして、さらに対策もSREチームから全体に展開しています。
チームのメンバーが語る、開発における楽しさ
これがトータルの説明なんですけど、「じゃあこれでどうだったかな？」と振り返ったときに、3つ「すごく楽しいな」と感じることがありました。
1つ目は、期待されるサービスを作っている実感。お客さんと近くで働くことで、「実際に使われるサービスを作ってるな」というのをエンジニアが感じられて、すごく充実感を感じられます。
2つ目は、ちょっと僕も関わっていたんですけど、盤石なインフラで機能価値を追求。アプリケーション開発に専念できる。
3つ目は、経験を蓄えてチームで解決。いろんな知見をプロジェクトに横展開したりというかたちで共有していくことで、みんなで解決してる感じが得られるので、すごく「Fun」「Fun」「Fun」と、「楽しいな」と思い、日々やっています。
最後に、僕らのチームはまだ実はけっこうやることがあって、引き続き拡大をしています。僕らもビックリするぐらい「ニーズってあったんだな」と感じていて、引き続き「We are hiring」というかたちです。
開発メンバーの声、昨年度も少し紹介したんですけど、「いままでの開発手法には戻れません」「新しい技術に触れられる」「みんなで作ると、非常に楽しい」というのがあります。
私個人も、やっぱりこのコメントと同じようなことをすごく感じていて、例えば自分がやりたいことを上司に言ったり、「やりたいです」と手を挙げると好きなプロジェクトにアサインしてもらえるとか。
私もけっこうもう30代半ばぐらいで、そろそろ一般の日本企業にずっといたら「マネジメントやれ」と言われることもあるのかもしれないですけど、「僕、もう少し現場でやりたいです」と言うと、実際にコードを書いてもいい、というのをやらせてもらえる。もちろん「もう少し全体をチームでまとめるのをやりたい」と言えば、そういう仕事もやらせてもらえます。
「具体的にどんなことをやっているか？」「他のプロジェクトはどんなものがあるの？」というのは、Qiitaで記事にしてもらっているので、ぜひお時間があったらご覧いただけたらなと思います。
では、以上で発表を終わります。ありがとうございました。
