導入事例インタビュー

2022/10/24
株式会社 mikan
バックエンドエンジニア
遼平
株式会社 mikan
2014年6月創業。『本質的なテクノロジー活用であらゆる人の英語学習によりそい人生の可能性を広げる』というミッションを掲げ、総ダウンロード数600万を超える英語アプリ「 mikan 」を運営。ベストトレンドアプリや e-Learning 大賞 Edtech 部門など、フューチャーや受賞も多数。2021年から人材採用にも力をいれ、1年で組織人数は倍以上に拡大。これまで以上に事業成長のスピード・幅を増し、会社一丸となりビジョンの実現に向けてチャレンジを続けている。
https://mikan.link/

スタートアップに必要な SRE の仕組みを作ってくれた

1人で抱えていたインフラの課題を相談したい

問い合わせフォームからのコンタクトが最初の接点でした。コンタクトしようと思った背景を教えてください。
私は mikan で最初のバックエンドエンジニアとして入社しました。SRE はいなかったので、経験が少ないながらも SRE の業務をしつつバックエンドの開発もしていました。知り合いの SRE からの話を参考にしたり、自分でも調査したりしながら進めていました。しかし、SRE に関する知見・経験が少ないため、モヤモヤした課題感を明確にできない状態が長く続いていました。
そのさなか、前職の上司から「インフラに課題感を抱えているなら Topotal さんに相談するといいよ」と勧めてもらったんです。また、別のタイミングで一緒に仕事をしたことのある SRE から Topotal さんによる支援を受けながら改善活動をしていると聞き、信頼できる2人からの紹介なら安心して相談できると思い、問い合わせをしました。
その際の問い合わせ内容は、インフラのレビューフローがない、オートスケールがうまく組めていない、どのくらいまで負荷に耐えられるのか把握できていない、これからのインフラの相談相手がいない、の4点でした。
そうですね。私の業務はバックエンド開発が中心なので、効率よく SRE の業務をこなしていく必要がありました。特にインフラのレビューフローの実現とオートスケールの構築は、豊富な経験を持った外部の力を借りたいと考えていました。

さまざまな課題を深掘り、改善を積み上げる

初回の打ち合わせや進め方は、どのように感じましたか?
何が課題かをゼロベースで考えてくれていると感じました。例えば、レビューフローがないこと自体が問題ではなく「レビューフローがないからこういう課題がある」と、踏み込んだ課題の洗い出しを最初の現状把握のフェーズでしてもらえました。
実は私たちが伝えた課題に対して、実際のコードを読んだり書いたりしてすぐに取り組んでいくのかなと思っていました。ですが、実際には「今の会社・サービスの規模なら改善する点はここ」という現実的な提案をもらい、mikan としてどう考えているかを議論しながら進めました。
課題や提案の説明は非常に納得感のある内容でしたし、1つ1つ改善を進められたので、私たちの課題に対する解像度も上がりました。
具体的な支援の内容や優先順位はどのように決められたのでしょうか。
具体的に支援を進めてもらったのは、インフラ構成と運用体制のレビュー、GKE クラスタ移行、コスト削減、モニタリングの4つです。
まずはじめにインフラ構成と運用体制のレビューを実施してもらいました。理由は、入社以来1人で構築してきた mikan のインフラ構成をプロ視点で問題がないかをチェックしてもらいたかったからです。また、全体のレビューから着手することで、Topotal さんに素早く現状把握をしてもらうという狙いもありました。
それ以降は、Topotal さんの視点で課題を洗い出し、そのうえで原因となる現在のインフラ構成の問題点を洗い出してもらい、優先順位の高い順に着手することにしました。GKE クラスタ移行はその中でも優先度が高かったタスクでした。プロダクション環境にも大きく影響するタスクでしたが、滞りなく進めることができました。
コスト削減ついては、クラウドのコストが上昇していることを確認したタイミングでラフに相談させてもらいました。Topotal さん側で工数をあまりかけずにすぐ改善できそうなところを見つけられたので、早めに取りかかってもらいました。
最後のモニタリングは、現在相談しながら進めているところです。mikan のユーザーを増加させるフェーズになった時に、ユーザー増加にどの程度耐えられるか、インフラにどこまでコストをかけて拡張するのかを判断するためにも、まずは現状把握をするためにモニタリングの取り組みを進めています。
インフラ構成・運用体制のレビューができたことで、よかった点はありますか?
レビューでは、Google Cloud Architecture Framework に則り、システム設計、運用、セキュリティ・プライバシー・コンプライアンス、信頼性、コスト最適化、パフォーマンス最適化の項目で、どれを優先すべき項目なのかディスカッションしていきました。
私はパフォーマンスのチューニングやセキュリティ、デザインの視点で考えていましたが、Topotal さんは可用性やログといった運用も含めたシステム全体を俯瞰した視点で考えていました。この視点の違いはとても勉強になりました。また、Topotal さんはさまざまな企業への支援をされているので多くの事例や経験を持たれています。mikan に似た事例や近い将来を見据えた事例を共有してもらい、成長フェーズや規模の違いを踏まえたアドバイスはとても参考になりました。
次に行った GKE クラスタ移行は、Topotal のメンバーと同期的に作業されてましたね。
はい、一緒に作業するのは楽しくかなり勉強になりました。中でも学びが多かったのはリリース作業です。開発環境でしっかり検証した上でステージング環境→プロダクション環境へ段階的に反映したり、作業手順を作成してた上でお互いの認識を揃えた上で作業を実施したりする様子から安全に作業を行う工夫を学ぶことができました。
すでに600万ダウンロードを超えて多くのユーザーが使う mikan のサービスでは、安定的に運用することも重要な要素の一つなので、このような丁寧な作業プロセスは参考になりました。
この頃には Topotal さんからの提案をもらいレビューして進める流れができていました。Topotal さんが能動的に対応してくれたので、私はほとんどの時間をバックエンド開発に注力できるようになりました。
クラウドのコスト削減は、定例会での相談でお話しいただいたのがきっかけと聞いています。
アクティブユーザー数の変化に比べるとクラウドのコストが思った以上に右肩上がりになっていました。直接的な原因は Firestore の Read Ops が跳ね上がっていることだと分かったため、定例会で Topotal さんに相談したのがきっかけです。
Topotal さんからインフラ構成の無駄の洗い出しだけでなく、開発環境やステージング環境のスペックを必要十分なレベルにスケールダウンしたり、API が稼働しない土日祝日や深夜時間帯には自動で止まるようにしたりといった対策の提案をしてもらいました。
特にステージング環境は開発者が API やインフラのコードを動かすだけでなく、QA チームや mikan PRO の英語教材を作るコンテンツチームなど開発しないメンバーも活用します。そのため「できるだけシンプルなインターフェースで、でも工数はあまりかけたくない」というわがままなリクエストでしたが、GitHub Actions を活用して開発しないメンバーでも使いやすいかたちにしながらコスト削減を実現してもらいました。その結果、月間のクラウド費用は15%ほど削減できました。
最後はモニタリングの支援ですね。
今回、一からモニタリング環境を作るために Topotal さんの支援を受けました。モニタリングの環境の構築は、Topotal さんからご紹介いただいた以下の3ステップに則って進めていきました。
  • 1.
    目的に合わせて網羅的に情報を取得する
  • 2.
    問題点を特定し、しきい値を設定する
  • 3.
    設定したしきい値を適正に調整する
当初、Topotal さんの支援内容は、現在のモニタリングに合わせて単にアラート設定や Slack 通知の設定を追加し、障害検知から対応に至るまでの仕組みを導入するようなイメージを持っていました。
しかし、実際にはモニタリングのあるべき姿に基づいて既存のモニタリングをゼロベースで見つめ直すところからはじまりました。「どのような状態を異常とするのか」を細かく確認をしながら進めたことによって、モニタリングの項目や通知の設定などを大幅に改善することができました。
また、mikan はローンチから数年経過していることもあり、システム基盤には数多くの改善点があります。このような状況の中で、はじめからシステム全体を監視しようとするのではなく、重要かつ緊急度の高い課題に焦点を絞って段階的に改善を行った点は非常によかったと感じています。
この頃には私の意識に変化がありました。
もともと、理想や結論にすぐ到達したくなる癖があったのですが、まず現状の把握と理解からはじめ、現実的な解決策がどこなのかを落とし込み、作業を進めていくように変わりました。このプロセスが身についた点は大きな変化だと感じています。

ドキュメントの文化はチームの可用性を高めてくれた

ご自身だけでなく、チームの変化も感じられましたか?
バックエンドチームが行う SRE の活動を社内に対してどのように伝えるとよいかについて Topotal さんに相談したことがありました。すると、Topotal さんから周知を目的とした成果ドキュメントの作成を提案され、すぐに作成してくれました。このドキュメントを私のほうでレビューして社内に展開したところ、かなり反響がありました。この一連の取り組みによってチームの活動を他のメンバーにも伝えられるようになりました。
バックエンドの作業や SRE の活動は、目に見える変化がないので価値が伝わりにくいと感じていました。ですが Topotal さんのまとめてくれるドキュメントは、社内の誰が読んでもなぜそうなっているのか、何を参照・引用しているのかが分かりやすいものでした。
現在バックエンドチームは3名になり、自分しか把握していなかったリソースや仕様をドキュメントにまとめ、共有できるようになったのは大きな変化でした。Topotal さんのドキュメントの文化は、チームの可用性を高めてくれたと感じています。

最後に Topotal へ一言お願いします。
Topotal さんの支援には非常に満足しています。私からはポジティブな意見ばかりです(笑)。友人や他社の知り合いから SRE やインフラに関する相談があった場合、ぜひ Topotal さんを紹介します。
私たちのようなアーリー期のスタートアップに必要な SRE の実践の仕組みづくりはもちろん、グロース期に必要となる SRE の実践を加速させるためのサポートもしてもらえると思います。
無料で相談する