Interview

新卒インフラエンジニアが描く
技術の資産化計画

インターネット産業の変化にあわせて様々な事業を提供している当社では、多様な技術領域において若手エンジニアが日々活躍しています。FEATUReSでは彼らの活躍を連載形式でご紹介します。

第3回目は、当社メディア事業の横断技術組織「技術本部」に所属し、インフラを担当するトルガエフ タメルランです。

内定者時代から様々なサービスのインフラに携わり入社1年目にして、幅広い視点を持つトルガエフ。多岐にわたるサービスの課題解決を通じ、経験と知識を重ねています。

「技術」を軸に横断的な貢献を目指す彼の「技術の資産化計画」をご覧ください。

Profile

  • Torgayev Tamirlan (トルガエフ タメルラン)
    技術本部 インフラエンジニア

    2018年 サイバーエージェント新卒入社
    株式会社サムザップでのインフラインターンシップ、サイバーエージェント 技術本部での内定者アルバイトの後、入社後は技術本部に配属。新規サービスの立ち上げや既存サービスのサポート、改善に携わる。

技術がサービスの課題解決につながることを知った

ー インフラエンジニアとしてサイバーエージェントで働くことのおもしろさは何ですか?

私は「技術的な議論ができる」ことを大切にしています。サイバーエージェントは事業が多岐にわたるため、特有の技術的課題に事欠きません。それを様々なエンジニアと議論しながら課題解決をできることが刺激的です。

その面白さを知るきっかけは、学生の時に参加したサイバーエージェント子会社 サムザップの「戦国炎舞 -KIZNA- 」(※ 以下 戦国炎舞)の就業型インフラインターンシップです。

2016年当時、ネットワークに多少の知識はあったにしろ業務経験ゼロからのチャレンジでした。今思えばインターンというより普通に実務に携わらせてもらい、それがまた刺激的でした。

実際の仕事を任されたことが新鮮だったということですか?

というより、技術的なチャレンジが、そのままサービスの業績につながることがわかり刺激的でした。

例えば「戦国炎舞」は1日数百GBという膨大な規模でログデータが発生します。特に1日3回行われる「合戦 (プレイヤー同士の集団戦)」は国内でも有数のトラフィックが集中し、膨大なデータの保管や集計にかかる時間に多大なコストがかかっていました。

この課題の改善をトレーナーの方と担当することになりました。詳しくはサムザップの技術ブログ(※)に書いてありますが、結果的にBigQueryを使用することで高速化とコストカットにつなげることができました。

ログ収集と解析の改善 (BigQuery編)  サムテック!– Sumzapエンジニアブログ –

ロギングのアーキテクチャを議論し、仮設を立てて提案, 検証, 実装を繰り返して課題解決につなげる。「戦国炎舞」にとってベストプラクティスが何かを探るために、エンジニア同士で議論しながらチームで解決していくことは何より楽しかったです。

そんな経験もあり、社内にある様々なサービスの技術課題に興味をもつようになりました。

サービスの技術課題で印象的だったケースは他にありますか?

入社して配属された技術本部は、サイバーエージェントの横軸インフラ組織です。そこで複数のサービスを担当しました。なかでも「AWA」のデータベース復旧改善の案件は印象的でした。当時、運用上のトラブルでデータベースが抹消されることが起き、その復旧には12時間かかりました。

私が携わったのは再発防止策と、同様の障害が起きた場合の最短復旧方法です。復旧時間の短縮については4ヵ月かけて完了しました。これもブログの記事(※)としてサイバーエージェントのDevelopers Blogに投稿しています。

DBが真っ白になっても55分で完全復旧ができるまでの道 (CyberAgent Developers Blog) 

復旧に要する時間は12時間から55分に短縮されましたが、当初の目標値は2時間での復旧でした。2時間あればユーザーや事業責任者に対しても「復旧するので待ってもらえますか」と言えるとチームで判断したからです。12倍以上の高速化が達成できてしまったことには驚きましたが。

こういった経験があって、プロダクトの課題, コスト, 機会損失などに着目すると、技術で様々な業績貢献ができることを知り、そのダイナミクスさに面白さを感じるようになりました。

複数サービスの技術課題を見ることで広がった視野

ー 横軸組織ならではのエンジニアリングの楽しさとはなんですか?

あるサービスに特化した技術課題を解決した際、会社全体のナレッジとして資産化していくことで、会社全体の技術力を向上させることができる事です。サービスが多角化しているので共通化させることは難しくもありますが、それができればサイバーエージェントが技術者組織として今よりもっと強くなるのでチャレンジしがいがあります。

というのも、サイバーエージェントにはログ、課金、 認証、画像処理、負荷対策などに大規模サービスならではの技術課題があります。例えば、秒単位で膨大なデータベース書き込みが集中するのはスマートフォンゲームならではの技術課題です。

各サービスでそれぞれの課題に向き合いますが、仮にその解決方法がそのサービスだけで完結してしまうと、会社全体に還元していきません。それにノウハウが属人化するリスクもあります。

また、複数のサービスで同じようなアーキテクチャやインフラ構成を使っている事をよく見かけます。各プロダクトで裁量権をもってアーキテクチャからとりくめるのがサイバーエージェントの良いところですが、ベストなソリューションがあるにも関わらずそれを知らないことで、各プロダクトで「車輪の再発明」が起きてしまうのはもったいないです。

更に何かトラブルがあった場合、網羅的にメンテナンスする必要がありますし、それが全サービスのどこに分散しているのかを探すだけでも多大なコストを要します。

このように、各サービスが直面する技術課題を共通化し、全社の技術資産にしていきたいと考えています。

ー 全社の技術資産とは具体的にどんなイメージでしょうか。

共通基盤は作るだけでなく使われなければ意味がないです。そのために入り口が重要になります。

例えば、Terraform(※)です。サイバーエージェントの多くのサービスでは、インフラストラクチャがTerraformで書かれ、管理されています。それ自体は良い事ですが、先程の「車輪の再発明」のように無駄な開発コストが発生します。

※ インフラの構築や設定をコードで表現できるツール

そのため「Terraformベストプラクティス」を作ることを考えています。そしてそのベストプラクティスの中に、サイバーエージェントのサービスでよく使われる、課金やログや認証などの共通基盤を組み込もうとしています。

なぜかというと、共通基盤の存在を知らないと、ロギングなどよくある機能を独自に作ってしまいがちだからです。そうならないためにも、共通基盤を周知するだけでなく、ベストプラクティスに組み込むことで、デフォルトで使われるようにすることを考えています。

それがうまくいくと「こうすると良いですよ」的な抽象的なベストプラクティスではなく、サイバーエージェントのサービス規模にチューニングされた、会社資産としてのベストプラクティスが提供できると考えています。

将来的には、各事業部や子会社と連携して「サイバーエージェントのベストプラクティス」を作れたらと考えています。そのきっかけとして、Terraformのベストプラクティスが良い結果になれば嬉しいです。

将来やりたいことはまだ見えないけど、方向性の土台は見えてきた。

ー インフラエンジニアとして各サービスとの関係性はどう構築していますか?

コミュニケーションの質と量を重視しています。具体的には、ちょっとした技術相談, トラブル時の対応などは即レスポンスするようにしています。インフラエンジニアは困った時の問い合わせ先みたいな印象になりがちですが、自分はパートナーとしてサービスに寄り添うようにしています。それこそ、サービスのエンジニアとリラクゼーションルームで雑談することを日々の楽しみにしています。

また、習慣として、各プロダクトのソースコードに目を通すようにしています。また、サービスの仕様や特性なども分かる範囲で知っておくようにしています。

そうすることで、リラクゼーションルームで「こんなことやりたいんだけど」と雑談をもちかけられた時に「今のサービスのフェーズ、状態、システム構成だと、こうした方が最適かもね」とその場で提案できたりします。

サービスのソースを読む習慣とか、気軽に話せる関係値づくりなどは「知る努力、知られる努力」の積み重ねで、関係性こそが大事だと思っています。なぜなら、再発防止や障害対応も大事ですが、潜在的なリスクを洗い出し、耐障害性を上げることの方が重要だからです。

サービス開発で不安に思うことやリスクに感じることは、本来なかなか言い出しづらいことですが、普段から近くにいて気軽に声をかけられるインフラエンジニアがいたりすると、雑談などからお互い情報共有でき、それが結果的に早期の予防策や改善につながったりします。

だからコミュニケーションスキルも含めて技術力だと自分は思っています。

ー 将来的にはどんなエンジニアになっていたいですか?

正直、決まっていません。ただ技術本部の仕事を通して、方向性の土台はできてきたと感じています。気を抜くと、目の前にあるタスクに埋もれがちですが、技術課題の半分は組織課題だと思っていますので、それを上流から解決できるようなエンジニアになりたいと思っています。

Page Top