ミッションに取り組むインフラ部門のマネージャー

はじめに

こんにちは、インフラ部門で GL (グループリーダー)を拝命している天野です。 DeNA での GL はマネージャー職であり、一般的な会社での課長くらいのポジションにあたります。また、エンジニアでもあるのでエンジニアリングマネージャーです。

今回のエンジニアブログでは、DeNA のインフラ部門のエンジニアリングマネージャーが上からどんなミッションを与えられ、メンバーにどんな指示を出しているのかを書いていきます。この記事が、インフラ部門での働き方の雰囲気を理解し、インフラエンジニアのキャリアパスを考える一助になれば幸いです。

組織のミッションと業務内容

まず私の組織のミッションについて説明させてください。一言で言えば「QCD の鼎立」です。 Quality（品質）、Cost（コスト）、Delivery（納期）、この相容れないものすべてをなんとかすることを求められています。

業務内容としてはゲームのインフラを AWS や GCP 等のクラウドを使って構築し運用することです。新規ゲーム用インフラの構築や、既存ゲーム用インフラの拡張や運用をしています。

その中身のシステムは gi という DeNA 独自の IaaS 運用のためのツール群を使ったり、GKE 等の K8s 技術を使用しています。データストアは、IaaS では MySQL や Elasticsearch、Redis、Memcached、マネージドなら Amazon Aurora、Spanner、Amazon ElastiCache、Memorystore などを使用しています。フロントエンドにある API サーバも合わせたサーバ全体の台数は数千台の規模になります。これらのインフラを私も含めて12人のメンバーで対応しています。

こんな環境で仕事をしている中で、QCD にどう向き合っているのかをそれぞれ紹介していきます。

＜Cost＞部長！そんなこと言われても、もうこれ以上コスト削減できないですよ！

インフラコストを低くできれば、その下げた分はまるごと利益が増えることに繋がるため、コスト削減は非常に重要です。だからこそ、継続的なコスト削減を求められます。ただ、これを毎年していると、さすがにもうやり切っただろうという気になってきます。そこで「部長！そんなこと言われても、もうこれ以上コスト削減できないですよ！」と声を上げたくなるわけなのですが、そうも言ってはいられません。

すでに、スポットインスタンスの導入、Autoscaling の導入、ゲームの人気変動に合わせて各種サーバスペックを最適なリソース使用率となるように調整、データベースの統合、みたいな大きな効果が見込めるものはほぼ実施済みです。そして、予算は前年の実績をベースに立てているわけで、そこからさらに予算比で削減する目標を掲げることになっています。

まだ見ぬ埋蔵金を求めて、必死に探すと、意外とまだまだ見つかるものです。実際2023年度は、数十万ドルのコスト削減ができました。まずは、BigQuery への Physical Bytes Storage Billing と BigQuery Editions の導入、Aurora Serverless v2 の導入、 Pod 集約率の見直し、新しくでたコスト効率のよいインスタンスタイプへの変更のようにクラウド側の仕様変更や新技術に合わせてコスト最適化することで、コスト削減を見込めるところをやっていきました。

更に、変更作業が複雑で後回しにしていたサーバのシュリンクもがんばって実施してもらいました。我々の IaaS は全サーバで1秒おきに vmstat の結果を記録してログとして保存しているので、後から秒単位での CPU や memory の使用率を確認できます。 Prometheus Node exporter でメトリクスとしても記録していて、Grafana で確認しやすくしているので、リソース使用状況の調査は容易です。これらを使って過剰スペックなサーバが無いかを系統毎にすべてチェックし直す事で、無駄なリソースを削ぎ落としています。

これを安全に実行するにはミドルウェアに対する知識も不可欠でして、例えば Elasticsearch は一見 CPU や Memory、Disk IO に余裕があるように見えても、実はページキャッシュがあるおかげで負荷が大幅に低く抑えられていたりすることもあるので、安易にインスタンスサイズを一つ下げると大惨事になったりします。他にも Memcached は接続追跡がボトルネックになることがあったりと、ミドルウェアごとにどんな仕組みで動いていてどこかボトルネックになるのかをよく理解しておく必要があります。これらのタスクを通して、アサインされたメンバーのスキルや経験が上がっていく事も嬉しく思います。

さらにビジネス要件にまで踏み込んで、開発環境の統廃合、新規開発システムの要件変更なんかもして、削れる部分は徹底的に削ります。

今までなんとなく S3 に保存していたそのバックアップは本当に必要なバックアップなのか？
ログの保存日数は実はもっと短くてもよいのではないか？
新規開発するこの機能は、こうなったらもっとコスト削減できるが要件的に妥協できないか？

などを確認していきます。

それでも目標額に届かないと、自分たちが直接管理していないアカウントを見に行き余分なリソースを発見して削除を依頼することで、あらゆる手段でなんとか目標金額を達成しました。

ところで、私はマネージャーで管理職ですのでメンバーの昇給やボーナスの一次査定をする立場にあります。そのために半年に1回の目標設定と評価があります。そして、グループのメンバーには、昇給やボーナス、承認欲求、成長して自己実現する事、などを通して気持ちよく働いてもらいつつ成果をあげてもらいたいです。期初の目標では「●万ドル相当のコスト削減施策を見つけてきて実施する」という内容を個別のメンバーに設定してもらい、目標達成にむけて頑張ってもらいます。

マネージャである私は「好きな AWS サービスは AWS Cost Explorer です。」と言ってもよいくらいにそれと仲良くなり、削れそうな箇所を必死に探して、題材で困っているメンバーに対して「これなんかどうかな？」と差し向けて、やってもらうことになります。そうやって振られたメンバーは、コストを試算し、設定変更の方法を調べ、前述の Elasticsearch の例のように安全性の担保を調べて進めていきます。

一般的にコスト削減を実施すると品質が犠牲になりがちです。安全のために必要なコストを知らずに削ってしまうことにより、後になって障害に繋がるかもしれません。それらの可能性をきちんと確認してもらうことは重要です。

これらは時に地道な作業でもありますが、無事に本番環境の構成変更まで無事故で成し遂げて、1-2ヶ月の頑張りで年間を通すと自身の年収を超える金額くらいが削減され続けるとなるとそれなりに達成感もあり、対象システムについての知識もついて、やり甲斐を感じてもらえると思っています。

＜Delivery＞チームのアウトプットを最大化せよ

マネージャーによく言われるのは、チームのアウトプットを最大化せよ、というものです。

仕事は無限に湧いてきます。他チームとのやりとりは issue、slack、定例のなかの会話等で受け付けて、内部管理用の JIRA にチケットを切る運用ルールにしてタスクを管理しています。また、メンバーにも何か気づいたことがあったら、遠慮せずにとりあえずチケットを切ってもらっています。

その結果、チケットは増える一方です。今のうちのグループの Pull Request の件数を数えてみると人間が作ったものだけでも2024年5月実績で200件以上、とまあまあ悪く無いような気はしますが、発生する仕事量に対して到底追いつきません。メンバー全員の定例ミーティングの時に、全員で新規に起票したチケットの棚卸しを行い、現在の忙しさとかの状況を鑑みて、やるかやらないか、やるとしたら誰がやるか、余裕がないので一旦先延ばしにするか、やるならどんな方針で進めるか、などを話し合って決めています。そして、私が3ヶ月に1回くらいのタイミングで全チケットの棚卸しをして、これはどう考えてももうやらないと判断したチケットは閉じています。どういう判断で閉じることにしたかを定例でメンバー全員に共有するのも大切だと思っています。

タスクの優先順位は、当然ながら納期があるものを優先しています。新規リリースにむけて準備しているゲーム環境の構築やその負荷試験、新しいイベントに向けての準備として一時的なリソースの拡張なんかは、インフラ部門が足枷となり全体の計画が遅れるということは絶対にあってはならないことだと考えているためです。それらを迅速に行うためには、IaC を綺麗な状態に保ち、再利用可能なモジュール構成にしておくようにコードの保守も必要です。この新規構築と IaCの保守には比較的大きめな工数的ウェイトを割いてもらっています。

エンジニアが成果を上げるにはまとまった時間が必要で、ミーティングとかに分断された細切れの時間はパフォーマンスを下げるものだと思います。なるべくまとまった時間を確保してもらいたいのですが、シニアなエンジニアになればなるほどミーティングが増えてきてそれができなくなってしまいます。ですので、なるべくミーティングは減らして差し込みも減らしてあげたいと思っています。

差し込みが発生するものの一つにサーバの故障対応があります。その策として、サーバの単純な故障対応は自動的に復旧させる機構を作って運用することで、エンジニアが呼び出されることを減らしています。

シニアなエンジニアほど、まとまった単位で仕事をお願いし、詳細も含めてお任せし、週1回の1on1や施策ごとの定例の中で進捗を確認していることが多いです。一方でジュニアなエンジニアほどマイクロマネージメント寄りになります。1on1の頻度も週2回ほどにして細かく確認するし、内容にも口を出します。そのときに、提案方式で「こんな懸念があるように思えましたが大丈夫でしょうか？」という言い方を心がけて、明確な指示ではないようにしています。これはゆくゆくは自発的にしてほしいという思いの現れであります。

最近は「世界一流エンジニアの思考法」という本に出会い、そうこれだよこれ！ということで、グループ内で輪読会をしています。グループ内のメンバー同士で思考法についての共通の前提知識を持ち、理想の働き方をイメージして話し合うことで、成果を最大化して迅速に進められるようになりたいと思っています。

＜Quality＞高品質な通常運用

インフラ品質の維持に必要なタスクを挙げてみると以下のようなものがあります。

故障対応
各所で自動化しているシステムの修正や改善
セキュリティ対応
- マネージドサービス(Aurora や GKE等) の EOL 対応
- OS やミドルウェアの更新

インフラ部門にとっての高いクオリティとは、高い稼働率を保つことです。グループ内で SLI と SLO を定義し、その目標達成にむけて努力しています。

基本的には同系統のサーバは複数台存在するので、1台が故障したとしても、すぐにそのサーバがサービスから切り離しできるならば影響は極めて軽微でユーザにはまず気付かれないレベルです。 GKE ではシステム側が自動的に故障ノードを切り離して対応してくれますし、IaaS では自前のシステムでそれを実現しています。

また、自動化がどうしても難しいものもあります。システム的に予期しない挙動の場合や、システムが自動復旧できないような故障の場合は、システムがアラートを発してオペレータを呼び出してくるようにしており、オペレータはその対応をすることになります。私のグループでは1週間単位の輪番で回しており、サービスに影響があるようなアラートは夜中や休日でも電話がかかってきて輪番の担当者が呼び出されるようにしています。

自動的に故障サーバを切り離すシステムや、先述した自動復旧してくれるシステムですが、手動介入が必要なことがあるたびにその原因を調査して、今後は自動的になんとかできないかを模索しています。この手の仕事は主に経験の浅いジュニアなメンバーにアサインしていることが多いです。ジュニアメンバーは不具合の根本原因を調査し、自動化しているシステムのコードを読んで理解し、どこを修正すればよいかを考えて改修し、実験して、シニアなエンジニアにレビューしてもらって、マージして本番に反映していきます。これら一連の業務を通して運用しているシステムの構造を理解し、夜間や休日に呼び出されたときにもだんだん対応できるように成長してもらっています。

そうして慣れてきているとはいえ、夜間や休日に呼び出されたときに一人で対応するのは怖いですよね。その対策としてリアルタイムで情報共有できるようにするために、トラブルシューティング対応用 slack チャネルを準備しておき、そこで対応ごとにスレッドを立てて実況中継しながら作業してもらうことにしています。ここにはアラート名、対応方針、仮説、打ったコマンドとその結果の抜粋などを転記してもらいます。

最初は面倒に思いますが慣れるとそれほどではなく、むしろメリットが大きいので各メンバーは積極的に対応してくれています。過去の対応履歴がすべてそのチャネルにまとまっているので、slack の検索機能で過去のアラート名を検索すると過去の類似の対応履歴が出てきますし、後から別のアラートがでてやり残しに気づいたときにホスト名検索などで経緯を追えます。

呼び出されていないメンバーも意外とアラートが鳴っていることには気づいてくれていて、シニアメンバーがリアルタイムでその slack スレッドにコメントしてアドバイスしたり、困ったときに助けたりしてくれています。

こうした助け合いで品質が高い故障対応と、メンバーの成長による長期的な品質改善をしていっています。

一方マネージャーである私はその空気感を作るために、ボーナスの査定基準として故障対応への参加状況という内部的な KPI を設定しインセンティブを持たせています。ジュニアメンバーの場合は故障対応を実施したかどうかで、シニアメンバーの場合はどれくらいジュニアメンバーを手助けしたか、みたいな基準ですね。

メンバーの皆さんは大変ありがたいことに、それに乗ってくださっています。インセンティブもその一因でしょうが、早く役に立ちたいという気持ち、強いエンジニアになりたいという思い、サービスの品質を維持する使命感、みんなで高品質な通常運用をしていこうという空気感が、これらを対応してもらえている主な要因だと思います。

シニアなメンバーには、「マネージドサービス(Aurora や GKE等) の EOL 対応」や「OS やミドルウェアの更新」のような大きめで長期間かかるようなタスクを丸ごとお願いして、対応してもらうことが多いです。まとまった単位で仕事を依頼し、進め方や対外的なやりとりも含めてお任せしており、マネージャはレビューで多少意見を言う程度です。