サーバーレスアーキテクチャーも大胆に導入！自律・自走できる組織作りを進めるカオナビのインフラチーム

タレントマネジメントシステムを提供する株式会社カオナビでは、サービスをSaaS型にシフトするにあたってAWS（Amazon Web Services）を全面的に採用し、サーバレスの基盤開発でもAWSのマネージドサービスを積極的に活用しています。

そのベースにある「運用しない運用」という言葉の意図や、計測・監視の取り組み、アプリケーション開発の経験も活用できる「自走するインフラ組織」について、インフラグループの大久保智之さんと新井健さんに聞きました。

※この記事は株式会社カオナビによるSponsoredContentです。

AWSへの移行から技術的な挑戦を進める
サーバレスを推進して温かみある手順から脱出
開発の経験も生かしたアプリケーション監視と指標
自動化の原則は自走と自律
カオナビではエンジニアを積極募集しています！

AWSへの移行から技術的な挑戦を進める

── プロフィール（後掲）を拝見すると、大久保さんは新卒からインフラ一筋で、新井さんはアプリケーション開発からインフラへという対照的なキャリアなのですね。そんなお二人が所属されているインフラグループについて教えてください。

大久保　カオナビの開発組織には、プロダクトとしての「カオナビ」に関わるプロダクト本部があり、アプリケーションを開発するサービス開発部と、インフラ基盤を開発するSRE部で構成されています。

私たちインフラグループはSRE部の中で、ざっくり言うならAWSに関わるところを全部を見ています。インフラの構築、基盤の改善、さらにサービス開発のメンバーとソリューション開発も行います。監視や障害対応を含むインフラの運用も仕事の一部です。

── プロダクトとしての「カオナビ」は2012年にオンプレミス型でローンチされて、2015年からSaaS型に移行するためインフラ基盤もAWSへの移行を進めたそうですが。

大久保　AWSへの移行そのものは、私が入社した2018年より前の段階で完了しています。私の入社時期にはAWSが提供している各種サービスの活用も進んでいました。Elastic Load Balancing（ELB）でAmazon EC2を冗長化し、Amazon Auroraでデータベースも冗長化、Amazon CloudFrontを静的コンテンツ配信に使うといった具合です。

よくあるWebシステムの構成ですが、その当時から「AWSでどこまでできるかやってみよう」とさまざまな技術的な挑戦もしていました。IaC（Infrastructure as Code）の取り組みも始めていて、Ansibleを試しているエンジニアがいましたね。

── そんな中で大久保さんはどんなタスクに取り組んだのでしょう。

大久保　当時はELBを利用しているといってもClassic Load Balancerだったので、Application Load Balancerに移行しました。2019年の夏ごろに完了しています。

大久保智之（おおくぼ・ともゆき）

株式会社カオナビプロダクト本部SRE部インフラグループマネージャー

新卒入社先のSES（システム・エンジニアリング・サービス）事業を提供する企業や、MSP（マネジメントサービスプロバイダ）事業の企業で幅広くインフラ開発・運用を経験。2018年9月にカオナビに入社し、インフラ基盤の運用や保守、整備を一貫して担う。2020年5月、マネージャーに就任。

サーバレスを推進して温かみある手順から脱出

── インフラグループでの取り組みにはどのようなものがありますか？

大久保　大きかったのはバッチ基盤の刷新です。これは私ともう一人のエンジニアでチームを組んで取り組み、1年近くかけて2020年1月にリリースしました。

それまでAmazon Simple Queue Service（SQS）とAmazon EC2を利用して作られたバッチ処理の機構を、業務仕様を整備してサーバレスに切り替えました。使った技術は、AWS Step Functions、Amazon DynamoDB、AWS Batchなどで、AWSの事例紹介にも掲載されています。

けっこう泥臭い取り組みになりました。帳票出力系のサービスが密結合していて切り離さないと動かないとか。リリースに使っている「温かみ」あるシェルスクリプトを、インタフェースを変えないように作り直すなどの苦労がありました。

サービスのリリース時にも、バッチ処理が実行されていない瞬間を見計らって、タイミングよくバッチ処理の機構をメンテナンスモードにしないとリリースできませんでした。まるで車がいっぱい走っている道路を渡るような感覚でした。新しい仕組みでは、そういうことを考えずオンラインでリリースできるようになって、かなり達成感がありました。「サービスを止めずにリリースできるようになったぜ」ということで。

── それは達成感のある改善ですね。最近の取り組みも教えてください。

大久保　最近の取り組みとしてはバッチ基盤と並んで、メール基盤もAWS Lambdaなどを使って改修しています。リリース処理のパイプラインも、AWS CodeDeployなどで実現しています。

以前のリリースでは、担当者がログインしてシェルスクリプトでデプロイしていました。最近はリモートワークを前提に考えなければならず、その観点でより安全なデプロイ方式を考えることにしました。現在は承認ワークフローにAWS CodePipelineを使い、安全性の観点で一定の成果を出せました。

ただ、AWS CodeDeployとAWS CodePipelineを使ったこの仕組みもまだ完璧ではなく、使ってみると新たな課題が見つかる状態です。継続的な改善が必要だと感じるところです。

── どういった課題があるのでしょうか？

新井　以前のデプロイは、既存のインスタンスに対する変更だったのですが、新しい仕組みでは新規にインスタンスを立てては破棄するという形に変わっています。デプロイ方式刷新の取り組みは全てが順調とはいきませんでした。リリースパターンによってはリリースに要する時間が前よりもかかってしまうといった課題なども出てきました。

AWS CodeDeployに切り替えてから半年以上はたちますが、非機能要件的な部分の洗い出しが完全には終わってなくて、課題を見つけては潰してを繰り返して継続的な改善を進めています。

新井健（あらい・たけし）

株式会社カオナビプロダクト本部SRE部インフラグループ

ソーシャルゲーム運営など複数の会社で、PHPやJavaによるアプリケーション開発のほか、専任のインフラ担当がいない環境でAWSの運用を兼任するなど幅広い経験を生かして、2020年1月にカオナビに入社。インフラエンジニアとして専任で担当するのはキャリアの中で初。

── サーバレス化の推進でエンジニアリングに変化はありましたか？

新井　インフラエンジニアが、コードを書く機会が増えていますね。AWS LambdaではPythonやGoを書いているエンジニアもいますし、アプリケーションのバックエンドを開発してきたエンジニアにとって、その知識も生かせるAWSのサーバレス系プロダクトはかなり興味深い技術だと思います。

開発の経験も生かしたアプリケーション監視と指標

── システムの監視や計測についてはどのように考えているのでしょう。

大久保　監視ツールでは、アラートやデータ計測にMackerelを、APM（アプリケーションパフォーマンス管理）にDatadogを使っています。ただし、アラートの精度が上がるようチューニングして、より深い形で利活用していくことにはまだ課題を感じています。

── アラートの使いこなしは運用の課題となるわけですね。

大久保　前職がMSP（マネジメントサービスプロバイダ）だったのですが、監視システムから1日で1万報ものアラートが来ていたら、とても全部は見ていられないです。不必要なアラートは「割れ窓理論」と同じで、治安悪化につながります。

── アラートへの対応について意識していることや工夫があれば教えてください。

大久保　運用品質において「障害発生時にどう動くか」を意識しています。ここはオペレーションのグループと一緒に、去年から取り組みを始めています。

障害対応は時間が勝負なので、緊急対応のフレームワークであるICS（インシデントコマンドシステム）を使って「どうやるか」を決めています。また、障害に至らず未然でなんとかなった事案についても、ポストモーテム（振り返り）を作るようにしています。

── 新井さんは、監視ツールに取り組んでいたと聞きました。

新井　私が2020年1月にカオナビにジョインして最初に手がけたのが、先ほど名前の上がったDatadogの検証および実環境への導入でした。それまでは監視ツールとしてNew Relicを使っていたのですが、費用面などでDatadogに移行することになったためです。

アプリケーション側のAPIのレスポンス、レイテンシーをAPMとして測定できるようにして、SLI（サービスレベル指標）とSLO（サービスレベル目標）を設定しました。Datadogのアカウントをアプリケーション開発側のエンジニアにも配布していて、リリースした時点でレスポンスが極端に悪いAPIがあると、APIのレイテンシーを見るなどしています。

「カオナビ」のアプリケーションは基本的にPHPで動いています。私は前職でアプリケーション開発をしていたので、バックエンドの作りはだいたい分かります。内部動作を把握できてボトルネックがなんとなく分かることは、インフラの仕事にも役立っています。

── アプリケーションエンジニアとしての経験が、インフラにも生きている形ですね。

新井　そういう意味では、Datadog導入の後に資料をとりまとめて、社内の勉強会で発表しました。サービス側の「使い勝手が悪い」「画面表示が悪い」といった課題に対して、ソースコードも見ながら「ここがボトルネックになっているようだ」と説明したり、「こういうアプローチで改善できそうだ」といった提案をしたりすることもあります。

── アプリケーションの改善にも役立っていますね。ところでSLIやSLOの話がありましたが、サービスの信頼性・安定性へのチャレンジについてはどのように進めていますか？

大久保　SRE（サイト信頼性エンジニアリング）という観点では、指標を作成し、週次で数字を取り、開発エンジニアを含めたミーティングでレポートしています。まだボトムアップな活動ですが、引き続き取り組んでいきたいと思います。

新井　これからSLIやSLOに対して、いかに真摯に取り組んで改善を進めていくかを考えています。インフラチームはもちろんアプリケーションのエンジニア、エンジニア以外の人たちまでも貪欲に巻き込んで、自走できるようにしていきたいですね。

談笑する大久保さんと新井さん

自動化の原則は自走と自律

── 現代のインフラ管理では自動化が大きなトピックになると思います。カオナビではどのような考え方で取り組んでいますか。以前のインタビューでは「仕事を減らす仕事」という言葉もありましたが。

大久保　まず前提として、自動化・仕組み化を意識しています。何回も同じことをやっているようなら「その仕事をなくせないか」と考える。それがだめなら「定型化して自動化できないか」を考える。こういったことは「運用しない運用」とも言っています。

基本的な考え方としては、仕事の枠組み・仕組みを定型化して、自動化することですね。まず人の手でいいから仕組み化して、ロジックや枠組みを作る。その上で「本当にやる意味があるの？」という仕事はなくす。人でなくてもできる作業はコンピュータにやらせて、自動化する。あるいは、依頼者が自分でできるようにセルフサービス化する。

── 具体的な取り組みがあれば教えてください。

大久保　ちょうど取り組んでいるのが、Amazon Inspectorというサービスを利用して脆弱性チェックする仕組みです。これまでAmazon Inspectorのレポートを作成する作業を手動で行っていたのですが、あるエンジニアが同じ作業を自動化し、人手を介さずレポートが出力されるようになりました。このように手作業をなくそうということが、原則の一つです。

── ほかにインフラにおいて大切にしていることはありますか？

大久保　時間の使い方をコントロールすることですね。トラブルが起きていたら、直すことが最優先です。サービスの継続や安定運用に関わる作業は優先します。

一方で、日々のタスクは他のチームが関わるか自分たちのチームだけで完結するかでは考えることも変わります。他のチームに関わるタスクはもちろん優先しますが、自分たちのチームのタスクにもどれだけ時間を取っていくか。優先順位や時間配分を含めて自律し、自走できる組織にしたいと考えています。

── タスクの優先度と自律・自走という考え方はどう関連するのでしょう。

大久保　例えば障害対応のタスクなど、各自が能動的に判断しないといけないこともあります。メンバーが自律・自走の観点を持っていないと、マネージャーがマイクロマネジメントをしなければなりません。チームで対応するときにも、それぞれが自分で考えて「こういうやり方はどうだろう？」などと意見を出し合いたいですしね。

新井　自律ということでは、「目標に対してどういうアプローチを取っているのか」を意識します。ゴールに至る道筋をどう作るか、どう期待値調整をするか。そこは個々のエンジニアに任されています。

── 最後にこれから取り組みたいことや、インフラ管理への思いをお願いします。

大久保　事業の全体最適を支えられる存在になりたいですね。インフラは縁の下の力持ちで、売上げや利益に直接貢献することはありませんが、SaaSという事業においてはいろいろな役割の人がプロダクトに向き合うことでサービスを提供でき、対価をいただいています。インフラのチームとして、自分たちの仕事で価値を提供していきたいと思います。

新井　エンジニアが技術要素を選定してボトムアップで提案することで、いかに課題を解決できるかが重要になってくると思っています。周囲を巻き込んで良いソリューションを提供することが、結果的にプロダクトの発展につながっていく。そういう考え方で取り組んでいます。

大久保　そうですね。現場の一人一人がボトムアップで、問題の発見と課題解決ができる組織にしたい。そして、大きな仕事はチームで力を発揮する。メンバーそれぞれの良いところを最大限に生かせて、苦手なことは苦手だと言えるような、そういうコミュニケーションが取れるチームを目指しています。

── それはいいチームですね。本日はありがとうございました。