スタートアップでのシステム監視
こんにちは。株式会社ビズパのプロダクト開発チームの白鳥です。
こちらはビズパプロダクトブログの記事になります。下記マガジンから過去の記事を見ることができます。毎月なにかしら記事が追加されていく予定ですので、興味があれば是非フォローしてみてください！
先月は吉留さんによる Elasticsearch の導入を行った話でした。検索機能には「曖昧な表現であっても検索結果に出してほしい」「ノイズになる情報は出してほしくない」といった相反する要件と、サーバ負荷や性能などの非機能要件が詰め込まれており、開発時の苦労もたくさんありました。ぜひ読んでみてください！
というわけで、今回はシステム監視のお話です。
自社サービスの開発をしているみなさん、システムの監視はしてますか？してますよね。ビズパも当然やってます。
スタートアップにおけるシステム監視の難しさ
ビズパはまだ20名規模のスタートアップで、エンジニアは3人しかおりません。エンジニアが3人しかいないとどうなるかというと、基本的に全員フルスタックエンジニアになります。
ある程度大きな会社であれば、SREなどインフラ専任のチームがあったりするのでシステム監視も任せていけますが、スタートアップの場合、
インフラ安定稼働のためのリソースを割かなくても、トラブルが起きない
いざサービス停止などのトラブルが起こったところで、影響を受けるユーザーが少ない
事業的にもインフラ投資するメリットが薄く、新機能開発が優先される
というステージにいます。
そもそもインフラエンジニアというのは、ビジネスサイドから見て何をしているのかわかりにくく評価されづらい割に、いざトラブルが起きると詰められやすいポジションでもあります。スタートアップは会社規模が小さく、ビジネスサイドとエンジニアの距離が近いので、なおさらインフラを頑張っていくモチベーションが保ちづらい環境になりがちです。
それでもシステム監視はしなければならない
それでもシステム監視は大事で、誰もサービスダウンしていいとは思ってないんですよね。
だからシステム監視はしていくわけですが、まだ事業が小さいうちからシステム監視をしていくメリットもいくつかあります。
サービスの品質を向上させるチャンスになる
インフラのコスト感を養うことができる
システム監視の文化を育てることができる
細かくみていきましょう。
サービスの品質を向上させるチャンスになる
新しいサービスというのはどうしてもバグがあるものです。サーバの負荷状況だったりエラーログを見ていくことで、開発のタイミングではなかなか発見できないエッジケースでのバグにも気付けるため、地道にコツコツとやっていくことでサービス品質を上げていくことができます。
もちろんリリース前にバグが潰せるに越したことはないのですが、検索フォームに絵文字を入力されると検索サジェストのAPIが500エラーになる（サジェスト以外はちゃんと動く）とか、ログを見てないとなかなか気づけないですからね…。
インフラのコスト感を養うことができる
スタートアップはサービスの方向性も変わりやすく、そのため機能開発をどんどん行っていくわけですが、それによってシステムのボトルネックなども変化しやすい状態と言えます。
今サーバの負荷がどのくらいで、どうなったらスケールを考えなきゃいけないのか、新しい機能を作ったときに負荷はどの程度増えていくのか、そういうことがぼんやりとでもわかっていると、新機能を作るときにどの程度のインフラ投資が必要なのかも見えてきます。
ビジネスサイドの人にとって、インフラのコストは特に想像するのが難しい領域です。開発の要望をあげている以上、開発リソースがある程度発生することは了承していても、毎月のインフラコストが増えるなんてことは想像すらしていないケースも多く、エンジニアがこのあたりまでしっかりと気にしてあげる必要があります。
システム監視の文化を育てることができる
これが最も重要な要素と言ってもいいかもしれません。
組織が小さいうちというのは文化を育てやすいため、早い段階で良い文化を作ってしまうと会社がスケールしていったときに効いてきます。
システム監視をするというのは、「エンジニアでないと読み解けない情報を、エンジニアがちゃんと読み解いている」ということなんですね。事業責任者が KPI 見てなかったらどう思いますか？エンジニアがシステム監視をしないのも同じことです。
例えば、「エラーログ見てたら◯◯機能にバグがあったので修正しておきました」とか、「先週リリースした機能のせいでDBのCPU使用率が上がってるので、性能改善の時間を取るかインフラのスケールアップを検討したい」というのを、エンジニアが言っていくべきなんですね。そうやって「うちのエンジニアは作るだけじゃなくてサービスをちゃんと見てくれているな」とビジネスサイドに感じてもらって、エンジニア主導でサービス改善してくれていいねと思ってもらうことで、良いサイクルを生み出せます。
そういうサイクルができてくると、開発チームとしてもシステム監視をやっていくインセンティブが生まれるため、システム監視するのが当たり前になっていくんですね。これがシステム監視をロクにしないままサービスや組織が大きくなっていくと、どこかですごく苦労することになります…
システム監視ってどうやってやるの？
そうは言ってもシステム監視をどうやってやるのかですよね。AWS Cloud Watch でダッシュボード作ったり、閾値を決めてアラート設定しただけでは足りなくて、日常的に見るようにしないといけません。
熟練のインフラエンジニアになると1日の仕事がシステムログを見ることから始まったりしますが、スタートアップでフルスタックエンジニアをやりながらだとなかなか継続していくのが難しいです。だって毎日見ても何の変化もないし
というわけで、ビズパでは毎週の開発チームの定例の中で Cloud Watch のダッシュボードを見るようにしています。アプリケーションサーバやDBのCPU使用率などのグラフをざっと見て、大きな変化があったら深堀りしていったり、500エラーが出ていたらエラー内容を確認するタスクを切ったりしています。
ビズパでは毎週リリースを行っていて、開発チームの定例もリリース日に行っているので、ちょうど先週リリースしてからの数字の変化が拾えるため、開発した内容の記憶が新しいうちに改善していけるのが良いところです。定例の中でやっているので、会議体としてルーチン化しやすい点もよいですね。
最後に
ビズパでは仲間を求めてます！
エンジニアも、そうでないポジションもありますので、ご興味のある方は是非、カジュアルに面談をしてみませんか。
▼採用HP
▼ご応募はこちらから！（カジュアル面談エントリーも）
▼Bizpaのことをもっと知りたい方はこちら！
この記事が気に入ったらサポートをしてみませんか？