開発組織全チームでサイト信頼性を高めるために、「Makuake」のSREチームが伝道すること
「Makuake」はアタラシイものやサービスが生まれることを応援するプラットフォームです。そのプラットフォーム開発を支えるマクアケSREチームに、「Makuake」ならではのサイトリライアビリティ担保について聞きました。 （2023/9/4 アップデート）
SREは開発を維持していくためのベースを作る伝道師
ー まず自己紹介をお願いします
稲村：僕はもともと非エンジニア業界からIT業界に転職してインフラエンジニアやSREを経験してきました。マクアケには1年ほど前に入社し、今年39歳です。
青木：マクアケに入社する前の経験としては、10人以下のベンチャーから大手外資系グローバル企業までさまざまなIT系企業で経験を積んできました。アプリケーションエンジニア歴が長かったのですが、クラウドインフラ領域に携わるようになり、現在マクアケに入って2年程SREをしています。38歳です。
ー SREチームのミッションを教えてください
稲村：クラウドインフラの運用保守を基軸に、システム全体の信頼性とエンジニアの開発体験(DX)向上に責任を持つチームです。クラウドインフラのインフラ部分だけではなく、CI/CDや開発本部で横断的に利用されているSaaSの運用も担っています。
「エンジニアの新しいチャレンジを素早く実現するために、マクアケ流のSREプラクティスを創出し伝道する」が現在のチームコンセプトです。
マクアケではここ最近、開発施策の数がどんどん増えてきていて、同時にスピードも以前より求められるようになりました。その影響で、今はいかにデプロイを素早くできるかという課題にフォーカスしています。エンジニアがチャレンジしたいことや新しい取り組みがスピーディに実現できるように、開発しやすい環境づくりをすることがSREチームの役割です。
青木：SREは役割ではなくプラクティスであると言われているんですね。サイトリライアビリティを高めて障害を引き起こすことなくサービスを運用するためには、全てのエンジニアがサイトリライアビリティを意識出来ている状態が理想とされます。そのために、開発者と運用者の垣根を無くして、安定的な運用管理を行う必要があります。そのためにSREというプラクティスがカギとなります。
僕たちSREチームとしてはサイトの信頼性を高める考え方や実践方法を開発組織内へ伝道し、エンジニア全員がSite Reliability Engineering（SRE）を実践できる状態を実現するのが目標です。サイト信頼性をSREチームだけで保つのではなく、開発組織の各チームが信頼性を意識した開発を行い、SREチームは積極的にフォローアップを行うという構図です。
▼参考文献
青木：開発側の｢たくさんリリースをしたい｣｢様々な機能を出していきたい｣という志向と、運用側の「システムを安定させたい」「たくさんリリースされるとバグを踏まれるかもしれない」という気持ちは衝突が生まれやすいのですが、それを解消するのがSREです。
いままでは開発（Development）と運用（Operations）が分かれていましたが、最近は「DevOps」という、開発とインフラ運用を一連の流れとして考える概念が主流になってきました。僕たちSREチームはこのDevOpsを実現していくために存在していると言えます。
ー ちなみに「Makuake」にとってのサイトリライアビリティとは何でしょうか？
青木：シンプルに、「Makuake」のユーザーがいつでもスムーズにサイトを使えている状態、と言えると思います。
稲村：システムの可用性ですね。「Makuake」は応援購入という新しい買い物体験を提供していますが、可用性という点ではECサイトと似た要素を持っています。サイトがきちんと表示されている状態をキープするというのが最も重要です。
例えばサイトが落ちてしまったらその分売上の機会損失になりますし、レスポンスが悪くなればユーザーが途中離脱をして購入率が低下してしまいます。「Makuake」の場合、大型プロジェクトの公開やテレビなど大規模なメディア露出があった際にリクエストが跳ねあがります。上下の振り幅が大きいというかはっきりしているのが「Makuake」の特徴かなと思います。アクセス集中があったとしても、問題なくサイトが機能する環境づくりが僕らの仕事だと思っています。
アタラシイ体験を提供する「Makuake」として、開発者のアタラシイへのチャレンジを後押しする環境を作る
ー SREチームの詳しい業務内容を教えてください
稲村：基本的にスクラムで2週間を1つの区切りとして開発を進めています。半期ごとにチームで取り組む課題を設定しているので、そのテーマを基に優先順位を決めています。
現在取り組んでいることとしては、MySQLアップグレードなど「顕在化している運用課題」の改善をメインに、デプロイの改善といった「将来の運用課題」に対しても先回りで着手したり、監視サービスを統合して運用コストを下げるなどを行っています。AWSへのマネージド化の移行も進めており、僕らが重要視している「速く簡単にサービス改善ができる環境づくり」を進めています。
青木：去年はDatadogの活用領域を拡大してシステムの可観測性を高め、問題が起きたときにその原因検出をしやすい環境づくりに注力していました。サービススタートから10年経ち、システムの複雑化により課題の特定が難しくなったりリリースに時間がかかったりしていたので、Working Groupでコンテナ化を進めるプロジェクトも行われていました。
▼Working Groupについてはこちらの記事もご覧ください
現在は土台が整えられたので、エンジニアがリリースしやすい環境づくりを行っています。E2Eテスト自動化の仕組みを作るWorking Groupのサポートをしたり、自動テストやデプロイフローを効率化することでデプロイのスピードを上げる部分に注力出来ています。
現在は運用負荷軽減を目的に、利用サービスのマネージド化を進めています。SREではトイル (toil/手作業で繰り返し行われる作業)を減らしていこうという考えがあり、自動化できることや他に任せられる部分はどんどん出していくようにしています。
稲村：マネージド化で我々の責任範囲を減らすことによってやるべきことが減るということはありません。僕個人的には、クラウドインフラの仕事はパズルを組み合わせるようなところが楽しいと思っています。ロールプレイングゲームに例えると、戦略を組み立てて、キャラクターをうまく配置して勝ち進んでいくといったイメージの仕事です。そういう意味ではマネージド化して他に任せられるところは任せてしまい、注力するべきところに集中していきたいと思っています。
ー SREプラクティスを進めるために、どのように他チームに働きかけていますか？
稲村：まず、マクアケの開発組織として特徴的だと思っているのが、SREチームだけでなく他の開発チームもインフラを触ることが結構多いことです。担当プロダクトに関して上から下までちゃんと見ますというスタンスのアプリケーション開発エンジニアが多く、インフラとの壁がないんですね。サイト信頼性を全員で担保しようという考えが浸透しているのだと思います。
青木：その中で指標を基に信頼性を保持するため、開発の各チームごとにサービスレベル指標（SLI）/ サービスレベル目標（SLO）を設定・導入しました。「サイトが安定稼働して信頼性がある状態」の定義を設け、指標に落とし込んでモニタリングを行います。チームによってもフェーズによっても定義や指標は変化していくので、定期的に各チームの開発者/プロダクトオーナーたちと話し合ってすり合わせをしながら調整しています。
SLI/SLO の取り組みは始まってしばらく経ちましたが、実際にはまだまだ道半ばといった状況です。サービス利用者のユーザージャーニーの認識を、プロダクトオーナー陣と揃えて、本質的に「サイトの信頼性が担保できている」とみなせる指標にしていくのが、目下頑張っているところですね。
さらに今後は開発組織内だけでなく、事業側や経営陣ともコンセンサスをとりながら全社でSLI/SLO指標をウォッチできるように巻き込んでいきたいと考えています。開発と運用コストのバランスを保ちながら、攻めた施策を投入する見極めをしたり、保守的に進めたほうが良い場面をジャッジするためにSLOを活用できるようにしたいと思っています。
ー 社内からのSREへの理解は十分ありますか？
稲村：インフラとしては「なにもない」こと、裏側が変わっていたとしても表では変わったように見えずに誰も気づかないことが理想なんですよね。何事も起きなかった状態を評価するのは難しいと思うのですが、マクアケでは成果を出した人をちゃんと表彰する文化があります。
週次で行う開発全体ミーティングでは各チームの成果を随時共有しており、チーム間の業務に対する理解度が高いです。表彰ではメンバーからの推薦数が多い人が選ばれるのですが、フロントだけに表彰が集中しているということはありません。インフラだから目立ちにくいというのは感じないですね。
青木：インフラはやっぱり安定稼働していることがすべてなので、トラブルが起きるのはマイナスなんですよね。トラブルが起きた際は怒られることが多いのが通説です。マクアケに入社して今までの会社と違ってびっくりしたのが、トラブルが起きて処理し終わった後、「対応してくれてありがとう」と言ってもらえるんです。プロダクトに愛着が強く、サービスの安定稼働に対する意識を全員が強く持っているからこそだと思います。
また、僕は費用周りの話を経理や役員と調整することが多いのですが、インフラを単なるコストと考えるのではなくきちんと話を聞いてくれるのも今までの会社と違うなと感じました。インフラは成果が見えづらい領域で、新しいソリューションの導入は比較的説明が難しいジャンルだと思います。ですが、マクアケはサービス自体がアタラシイものを扱っていることもあり、自社で新しいことを導入することに対して理解のある会社です。それにスタートアップのスピード感もありますし、ひと言で言えばエンジニアに優しい組織ですよね。
安定を目指すだけでなく、攻めの姿勢も持つホスピタリティ集団
ー SREとして大切にしていることを教えてください
青木：SREをやる人は、サッカーで言うと自分でゴールを決めるタイプよりは、うまくパスをしてゴールをアシストするタイプの人かなと思っています。他チームが困っていることを一緒に解決したり、開発者がやりたいことを実現するための基盤を整えるホスピタリティを持っている人の集団ですね。
SREチームは開発基盤や環境、ツール群が当たり前に動くことを担保するのが責務であり、開発チームが伸び伸びと開発し、良い成果を出すことが僕らの成功だと思っています。
稲村：フォロワーシップの考え方は大事にしていると思います。開発が安全にかつスピーディにリリースを行えるようにして、何かあってもすぐに戻せる状態にしてあげたいという気持ちがすごくあります。保守だけではなく、前に進められるサイクルをつくるアグレッシブな部分も持っているチームだと思っています。
ー 今後チャレンジしたい事を教えてください
青木：リリースをもっと速く安全に出来るようにしたいと考えています。具体的には、長年使っているJenkinsの老朽化への対処と、リリース前の手順が複雑化している部分の簡略化です。モダンなツールを導入し、リリースを小さくがんがん回せるようにして、戻すのも簡単にできるという世界観を目指しています。エンジニアがリリースする際の負担を減らすことで、機能開発に時間を割けるようにし、リリース量を増やして開発のスピードを上げていこうとしています。これはSRE的に非常に面白い領域なので今後さらに極めていきたいですね。
また、開発チームとのコラボレーションも増えており、各チームが抱えているインフラに関する課題をSREがサポートする取り組みを進めています。チームが自立してインフラ領域も触れるようになるお手伝いをしていく感じですね。インフラとアプリケーションの垣根なく仕事を進めたい方にはマクアケは楽しいと思います。
稲村：10年続いているサービスなので、レガシーな部分もたくさんあり、インフラの新陳代謝を加速させることが目下の注力事項です。サービスを可能な限り落とさずに滑らかにシステムを入れ替えていくことをやっていきたいと思っています。表にはなにも影響を出さずに裏側でスムーズに切り替えるのは職人芸というか、かなりチャレンジングな仕事だと思うので、そこを楽しめる方と一緒に仕事が出来たらと思っています。
-----
いかがでしたでしょうか？マクアケの開発本部では現在エンジニア採用を行なっています。もっとマクアケについて知りたい方は、社員インタビュー記事や以下リンクからカジュアル面談・エントリーのお申し込みください！
◉エントリーをご希望の方
◉カジュアル面談をご希望の方
◉マクアケの中の人を知りたい方
この記事が気に入ったらサポートをしてみませんか？