本記事は、ソフトウェア開発者向けのオンラインメディア「CodeZine（コードジン）」からの転載記事です（オリジナル記事）。
エンジニアの半数以上が交代制でオンコール当番を担当
株式会社ココナラの主な事業は4つ。テレビCMでもおなじみの日本最大級のスキルマーケット「ココナラ」と、3,000名以上の弁護士に相談できる「ココナラ法律相談」、2021年に開始した法人購入者向けに特化した「ココナラビジネス」、そして2022年に開始したITフリーランスと企業の業務委託案件をつなぐ「ココナラエージェント」だ。
川崎氏は、株式会社ココナラに2020年に入社。同社が提供するプロダクトのインフラ部門と社内情報システム部門を率いている。事業の成長のためにはプロダクトを支える堅牢性とアジリティの高い基盤が必要だと考え、さまざまな技術課題の解消に日々取り組んでいる。川崎氏は「個人向けだけでなく、法人向けの事業にも注力し『ココナラ経済圏』のようなものを作ってどんどんプロダクトを成長させていくのが直近の動きです」と語る。
ココナラの各プロダクトはAWS上で稼働している。川崎氏は「システム構成としてはAmazon EC2やコンテナなどの環境で、プロダクト自体はAWS上で完結しています。ほかに、分析基盤はGoogle Cloud、検索基盤はElastic Cloudと、各種クラウドサービスのいいところをうまく活用しています」と説明した。
成長を支えるエンジニアの人数も増えている。在籍エンジニアは、川崎氏が入社した2年前は30名強だったが、2022年12月時点で60名を超えている。エンジニア組織としては、フロントエンド、バックエンドといった領域に分かれ、プロダクトインフラと社内情報システムの領域を担うのが川崎氏のグループだ。現在も積極的にエンジニアの採用活動をしており、川崎氏もイベントへの登壇やテックブログ・事例掲載の寄稿、インタビューなどでの情報発信によって貢献している。
インフラ運用は、インフラエンジニアだけでなく、フロントエンドやバックエンド領域のエンジニアも担当する。
川崎氏は「40名弱のエンジニアがシステム運用に携わっています。24時間・365日稼働しなければならないプロダクトなので、インフラのメンバーだけでは対応できません。日々のオンコール当番を設定しており、開発メンバーも保守を担当することがあります。インフラだけでなく、アプリケーションのトラブルもあり、また新しく入社する人もいますので、オンコール当番は技術領域や習熟度によってバランスよくなるよう工夫しています」と述べた。
ビジネスの拡大で増えるアラートに対処していくためには
ココナラでは、川崎氏が入社する以前の2016年からPagerDutyを活用している。導入の経緯について川崎氏は「2016年当時はおそらくエンジニアの人数は10名から20名程度でした。24時間・365日の安定稼働を実現するには多くの人数が必要ですし、アウトソースするにもコストがかかります。SaaSのPagerDutyなら費用対効果が高いと判断したのではないでしょうか。私も前職で、PagerDutyを費用対効果を鑑みて、同じような理由で採用しました」と説明した。
コミュニケーションツールとして使っているSlackにアラートの通知を送っているものの、即座に対応するための架電というアクションにつなげにくいし、外部委託のコストもかけたくない。そこでPagerDutyに各種アラートの発報を任せ、DatadogやAmazon CloudWatch、Sentryなどの監視ツールとも連携して、優先度を見極めた発報が行われている。川崎氏は「PagerDutyがなかったら相当つらいです。私たちにとって、なくてはならないシステム運用を支えてくれるソリューションのひとつです」と述べた。
ビジネスが拡大していくに従って、システム運用やインシデント対応の役割も重要さを増す。リリースの速度が増えると不具合が起きる確率も高まる。エンジニアも増えているのでナレッジの共有も課題となっている。そもそもどんなアラートを発報するかといったエラーの扱いも試行錯誤が必要だ。アラートを鳴らして誰かが気づけばいいというスタンスでは、不必要なアラートが増える一方だ。
そこで川崎氏は、オンコール当番だけに負担がかからないように担当エンジニアもアラートを気に掛けるといった運用の工夫をしている。オンコール当番のオンボーディングのためにTipsのデータベースを構築したり、インシデント対応を効率化するためのランブック（作業手順書）を拡充したりする地道な活動を続けてきた。
「しっかりアラートの内容を確認して、これは本当に発報するべきなのかをPagerDuty側に設定し、フィルターをかけていますので、既知のエラーでスルーしてもいいものは発報せず、未知のものと対応が必要なものだけを発報するようにしています。PagerDutyで検知した内容をフックしてAWS Lambda経由でランブックを流すこともしています。このような運用を愚直に行い、積み重ねています」（川崎氏）。
エンジニアの負荷を下げつつ、サービスを提供し続けるために
PagerDutyの活用によって、アラートの絞り込みによる効率化が実現した。1日に対応するべきアラートはリリース状況などによって波があるが、平均すると3〜4件程度となっている。オンコール当番制度もあって平均確認時間（MTTA）は日中では1分以内となっており、 平均修復時間（MTTR）についても暫定対応は1営業日程度に抑えている。
川崎氏は、PagerDutyの効果について次のように評価した。「当番制にしていなければ、誰がそのアラートを拾いに行くかをためらってしまい、MTTAは10分前後かかっていてもおかしくないと思います。今はみんな意識高く実直に対応していますので、MTTA、MTTRともに短くなっています。
さらに、エンジニアにかかる負担はかなり下がりました。24時間・365日の監視運用体制を構築したら膨大なコスト増加に繋がりますし、本当にPagerDutyは頼りにしています。経営陣も、サービスを止めずに提供するという、お客様にとって当たり前のことが実現できていることについて非常に満足しています」
今後もアラートの数を減らすなど、運用効率を高めるためにPagerDutyでの運用に磨きをかけていく。まだ利用していないインシデント分析の機能を使ってリリースの品質や基盤の不安定さを確認し、インシデントの再発を抑制するといった使い方も検討している。
2021年からサイバーセキュリティも担当するようになった川崎氏は、セキュリティインシデント対応におけるPagerDutyの活用も視野に入れている。そして、さらに中長期的にはシステムの可用性を高めるためのマルチクラウドにも挑戦する構想を抱く。
今後PagerDuty側に期待することについて、川崎氏は次のように述べた。
「アラートをトリアージする機能を機械学習的なアプローチで実現できたらと思っています。アラートの傾向や過去の対応履歴から対処法をサジェストしたり、第三者の視点からアドバイスをしていただけると、私たちの運用がもっと楽になると思います。
インシデント分析の機能についてはあまり使いこなせていないので、効果的な使い方のハンズオンコンテンツがあれば活用したいですし、勉強会やユーザー会などの交流の場があれば参加したいなと思います。今後も、PagerDutyのみなさんと当社の二人三脚でいいインシデント対応を実現していきたいと考えています」
デジタルオペレーションの現状
PagerDutyのWebサイトでは、インシデント対応などのリアルタイム作業の増加が、どのように技術チームに負担を強いているのかを明らかにした、「デジタルオペレーションの現状」のeBookを公開しています。ぜひ、本記事と併せてご参照ください。
