2024.12.19
システムの穴を運用でカバーしようとしてミス多発… バグが大量発生、決算が合わない状態から業務効率化を実現するまで
Verdaに関わる20代の若手エンジニアが語る、インフラ開発エンジニアの魅力(全1記事)
提供:LINE株式会社
リンクをコピー
記事をブックマーク
城倉弘樹氏(以下、城倉):「Verdaに関わる20代の若手エンジニアが語る、インフラ開発エンジニアの魅力」というテーマで、カジュアルセッションを始めたいと思います。よろしくお願いします。
このセッションは、LINEの基盤がVerdaというプライベートクラウドの上で動いているんですけど、それに関わっている比較的若めなエンジニアがしゃべるカジュアルなセッションです。
アジェンダは、まず我々の自己紹介をしたのち、Verdaというのがどうなのか、何なのかを簡単に紹介します。そのあとはここにディスカッションと書いてあるトピックのとおり、入ってどう変わったか、自分たちの強みだなどのポイントに関してかいつまんでしゃべっていこうかなと思っています。
みなさんは「LINE LIVE」のQ&Aで質問できるんですけど、そこに書いてある質問が適宜取り上げるべき内容だったら、より優先的にかいつまんでお話していこうかなと思っていますので、お気軽にいろいろと質問をしてくれたらよいかなと思っています。
最初に我々の自己紹介をサッと短めに1人1、2分ずつやろうかなと思っています。左側から、内海さんからお願いします。
内海究氏(以下、内海):プラットフォームチームの内海です。LINEには半年ほど前に入って、もともと学生時代にネットワーク系の研究や運用開発をしていて、新卒で入った前社ではWebのフロントエンドやバックエンド、モバイルアプリやデータ分析のHadoopのジョブを書いたりしていました。
1年ほど前に、やっぱりインフラ寄りのコードの開発や運用をしたいなと思って、LINEに入ってきて、今はOpenStackの開発運用をしています。
城倉:ありがとうございます。次は真ん中の早川さんお願いします。
早川侑太朗氏(以下、早川):早川侑太朗と申します。LINEには去年新卒で入社しまして、Verda室のネットワーク開発チームというネットワークソフトウェアの開発を主に手掛けているチームでロードバランサの開発、運用、ユーザーサポートなどをやっています。
学生の頃は少しだけWebフロントエンドのアルバイトをしたり、少しだけ研究室ネットワークの運用をしたり、そういうことをやっていました。残りはほとんど研究みたいなことに費やしていて、研究職のインターンに行ったりしていました。
そこでやっていた研究の内容と今の仕事が似たような感じで、その知見みたいなものが活かせそうかなと思って、今の仕事を選んだ感じです。よろしくお願いします。
城倉:ありがとうございます。最後、私がMCも兼任で務めます、城倉弘樹と申します。早川さんと同じチームでソフトウェアエンジニアをやっています。
早川さんが今ロードバランサと言いましたけど、私はロードバランサではなくてNATとか、今はVPCみたいな機能をクラウドで作ったりしていて、そのへんの新しい機能の開発などに最近は注力しているソフトウェアエンジニアになります。作ったサービスのリライアビリティエンジニアリングなど、わりと広いことに関してやっています。
入社した経緯はいろいろあるんですが、前職は大規模なネットワークプロバイダで働いていて、そこでR&D系の仕事をして、日々研究者と「こうだ、こうだ!」と言いながら働いていました。今はわりとプロダクションサービスに近いところのネットワークサービスをソフトウェアで作ることに注力してやっています。
こんな感じで、よろしくお願いします。この3人で25分くらいしゃべります。
城倉:実際にトピックにダイブして話していく前に、我々の組織、LINEのインフラに関わる網羅的な部分を簡単に説明したいと思います。我々はVerda室という、「Verda」という名前がついたチームで働いています。LINEの提供しているプライベートクラウドを提供しているチームです。開発したり、運用したりしています。
実はVerdaすべてがLINEのインフラではなくて、LINEのインフラはほかにもそういったプライベートクラウドがつながっているネットワークだったり、物理のサーバーは別のチームが管理していたり、Verda以外のサーバーも管理しています。
サーバーの管理などの部分を、システム室というチームがやってくれています。あとはネットワークのコンフィグレーションや、エクスターナルネットワークのピアリングデザインなどはネットワーク室の方たちがやってくれています。
我々はそういったローレイヤーなものにアタッチしてプライベートクラウドを提供するVerda室です。LINEではそれら全部を合わせた組織をITSC、IT Service Centerという部門で管理しています。
そのVerda室に今日はフォーカスします。Verdaはプライベートクラウドを開発して提供しているチームです。Verdaの中でもVMのほかにもネットワークのサービスなど、いろいろなインフラ機能があります。
Platform-IとPlatform-Kというチーム……「I」はInfrastructureで、KはKubernetesのようなものを管理・開発しているチームです。Networkは、私や早川さんが所属しています。ロードバランサやネットワークファンクションに関するサービスを、提供したり開発しているチームです。今回はメンバーの関係で、メンバーがいるところだけスライドに書きました。ほかは統一しちゃいました。
そのほかにもReliability Engineeringに対して、中心的な責任を持つチームだったり、プライベートクラウドのUIを開発しているチームだったり、いろいろなインフラサービスを提供しているので、それのクオリティを管理したり、いろいろチェックしてくれるチームなど、さまざまな組織で動いています。
城倉:Verdaに関して、もう少し詳しく説明します。Verdaは2016年から提供を開始しているOpenStackベースのプライベートクラウドになります。たしか、Verdaは何語だったんですかね?
早川:エスペラント語かな?
城倉:エスペラント語ですね! さきほど、うちの偉い人がメインセッションで言っていましたけれども、LINEのインフラなので、緑という意味です。
ここに書いてあるような、たくさんのインフラを提供していて、もちろんOpenStackなのでVM、ネットワークの基本的な部分、DNS、VMのイメージ管理。そういったNovaやNeutronやGlance、Designateなどの基本的なOpenStackのコンポーネントに加えて、インハウスで開発しているロードバランサ、ベアメタルインスタンスのサービス、最近提供開始しているNATのサービスなどもいろいろあります。
そういったOpenStackのインフラをベースに、ほかにもいくつかサービスを提供しています。例えば、Kubernetes as a Serviceをインハウスで開発して提供していたり、MySQLやElasticsearch、Kafkaなど、いろいろな追加のマネージドサービスも提供したりしています。
そんな感じですかね。このへんに関しても「ここどうなってんの?」などの疑問がありましたら、ぜひ質問で聞いてください。
スケールもそこそこ小さくはない数字になっていて、例えばスライドに書いてあるとおりなんですが、VerdaはVMが合計で5万5,000台以上提供しています。Physical Machineというのはベアメタルインスタンスで、これも2万台以上提供していたり、Hypervisorも2,000以上という大きなスケールになっていると思います。
たくさんOpenStackのクラスタを立てて、その上に別々に多くのVMを作るのではなく、リージョンごとに少ない数のOpenStackクラスタを立てて、その上でこれだけの数を何分割かしながら管理しています。単一クラスタのスケールが、ものすごく大きいクラスに入るかなと思います。
VMがこの半年くらいでどれくらい増えているかと言うと、こんな感じです。このペースでどんどん増えていくと、この数値ももっと大きくなるかなと思います。
あ、質問いただきました。「モバイルアプリの重さを感じるので、回線がデータを処理するために、よりよいインフラを手に入れる可能性はありますか?」。難しい質問ですね。このへんはあとでかいつまんでお話しいたします。
城倉:ここからは、さきほどディスカッションのアジェンダに書いた内容を拾いつつ、みんなで話していく感じです。気になるポイントがあれば、質問を適宜いただけたら、うれしいと思っています。
重要なポイントがあって、時間などいろいろなトピックの兼ね合いもあるので、全部の質問を拾えない可能性もあります。その点については、もし興味があればTwitterや、ほかのSNSで追加で質問していただけたらいいかなと思っています。
LINEに入って、我々はわりと最近LINEにジョインしたメンバーで、内海さんはまだ1年経っていなくて、早川さんは1年少し経って、僕も最近やっと1年になったくらいです。LINEに入ってなにか変わったか、そういうポイントに関して話してみたいなと思います。
(質問を読んで)「Verdaクラウドが公開される可能性はありますか?」。現時点ではありません。ただ、外部で連携していて、業務委託でLINEとコラボレーションしつつ、なにかしらのサービスを開発している方たちは、LINEの社員じゃないけどVerdaを使うことができるようになっています。
完全なるプライベートクラウドと、セミハイブリッドなパブリックっぽく提供しているクラウドもあるので、そのへんはこれには限りがないかなと思います。原則、これはパブリッククラウドサービスとして商品として売り出すことは現時点ではやっていません。でも、それくらいの品質になったらいいなと、みんなで思っているところはあると思います。
じゃあトピックにいきたいと思います。「Joining LINE, Before & After」です。LINEに入る前にどんな感じでしたか? みたいなポイント。今入ってみて、どんな仕事をしていて、どうですか? こんなことを軽く振りつつ、いろいろとしゃべってもらおうかなと思います。内海さん、どうですか?
内海:僕はLINEに入る前にフロントエンドを書いたり、Webのバックエンドを書いたり、モバイルアプリを書いたりしていたので、技術的なところから見ると、正直ぜんぜん違うことを今やっている感じです。
僕たちが今作っているサービスをインフラのプラットフォームと見ると、入る前はそのインフラプラットフォームのユーザーとして使っていて、入ったあとはその開発者のほうに移ったと感じています。
城倉:わりと内海さんに関しては、前職と大きく違うようなことにチェンジして仕事をしている感じですよね。
内海:そうですね。
城倉:ちなみに早川さんはどんな感じですかね?
早川:僕は学生時代、使う側としてはアルバイトで少しだけWeb開発のアルバイトのようなものをやっていて、そこでAWSを少し触った感じです。なので、使う側の気持ちに立つみたいなところで言うと、あまり立てていないような気もするんですけど(笑)。
運用する側としても、本当にプロダクショングレードのインフラをガッツリ運用することはやったことがなくて、わりとその場限りのイベントネットワークの構築に少し関わったり、研究室ネットワークも少しだけやってたり、それぐらいですかね。
城倉:早川さんに関しては、インフラのネットワークサービスはやっていないけど、ネットワークつながりで、なにか近いものをやっていたポイントに関してはTrueなのかな?
早川:そうですね。主に研究でやっていたOSのネットワークの機能などが一番わりと強いところというか。自分なりに詳しいところかなとは思っていました。あまり仕事で使うような技術スタックに関してはそこまでだったかもしれませんね。
城倉:そうですね、わかります。僕もだいたい同じ感じで。さきほど軽く言いましたけど、前職ではR&Dでソフトウェアルーターを作っている仕事だったんですけど。今、ソフトウェアルーターをLINEのプライベートクラウドでそのまま使うために作るぞ! みたいなことはそんなにやっていなくて。
Linuxとかよしなにソフトウェアルーターを構成できるものを使って、プロダクションサービスを作るケースです。より僕は応用的なポイントにきたかなと思います。
早川さんも言いましたけど、PoCみたいなケースではなくて、実際にユーザーが付いてLINEのプロダクションサービスに使われるバックエンドで、なにかしら活躍する系のものなので、責任感は上がったなぁと思っていますね。
いかんせん、国内やアジアで重要なサービスを抱えている会社ではあると思うので、そういった楽しみはみんな感じながら、ヒィヒィ言いながら働いてはいると思います。
城倉:ちなみに僕ガッツリ内海さんがどんな仕事をやっているかというのをあまり聞いたことがなかったんですけど。軽く教えてもらってもいいですか? 僕のわかるレベルで(笑)。
内海:基本的にはOpenStackの開発運用があって、大きめなプロジェクトが走っているときはそれに関連するタスクと、あとそれに加えて日々の細かい性能改善や、細かいカスタマイズ、バグを見つけたときのフィックスなどをやっています。
僕が重めに関わったプロジェクトだと、OpenStackのReliabilityやトラブルシュートのために内部のメトリクスを取得するOslo Metricsというプロジェクトをやっています。
細かい内容は「Open Infrastructure Summit」で発表している資料があるので、もし本当に具体的にどういうプロジェクトの中でやっているのかが気になる人がいたら、それを見ていただけるとわかると思います。
僕は正直入って半年くらいなので、それくらいしかやってない感じですね。
城倉:入って初にでかいことやる系のスピーディーさに、僕はびっくりしました。いきなり入ってOslo Metricsをやるのは、いきなりテックシェアがドーンって始まって、初めて会った人とビデオ会議で、Reliability Engineeringの根幹の部分をいろいろ調べるみたいなことですよね?
内海さんは分野は変わりましたけど、「まあ、Oslo Metricsくらいなら大丈夫ですよ」みたいな感じなんですかね?(笑)。キャッチアップが早いなと思っているんですけど。
内海:そうですね。もちろん、仕事が振られてきたからやった、という部分はあるんですけど、振られた時はけっこう大きい仕事をいきなり振ってくれるなとは思いました。
ただ、分野は変わったんですけど、別にそこまで普通にプロジェクトを進めるうえで大きく違うかというと、そこまで前職と違いもなかったんですよね。チームで開発して、コードを書いて、なにかあったらほかのチームに協力お願いして、プロジェクトを進めていくところでは、そこまで大きく違わなかったんですよね。そこまで大変ではなかったかなぁと思います。
城倉:すばらしい。それはすごい話ですね(笑)。
早川:それが当たり前にできるのがすごい。
城倉:ちょうどいい質問が何個かありまして。「英語力必要ですか?」とか「日本人じゃない国籍の方は何人いますか?」「何語使っていますか?」とか、いろいろありますが。
求められる英語力はチームによって違います。例えばPlatform-I、Kって書いてある部分は100パーセント英語でやっていると思っています。内海さん、それ合っていますよね?
内海:はい。基本的には英語です。半分くらいのメンバーが日本の方ではないので、英語です。
城倉:なのでドキュメントは当たり前のように英語だと思いますし、ビデオミーティングとかも基本的には英語でやっています。ネットワークチームは今のところ全員日本人、今日の時点では日本人オンリーです。プロジェクトによっては英語でやっていたり、外国籍の方がいたので英語でやっているチームもあって。早川さんはそうですよね?
早川:そうですね。ロードバランサのチームは、福岡の支社のメンバーともコラボしてやっていたので、そちらのほうには外国の方がいらっしゃったので全部英語でやっていましたね。
城倉:僕に関しては、残念ながらあまり英語で仕事はしていなくて。というか、「残念ながら」なのかどうかわからないですけど(笑)。あまり英語が得意ではないながら、私の個人的な業務に関しては、今のところチーム内での連携に関しては基本的には日本語でやっています。
ただし、内海さんのチームとなにかしら議論する時や、突然OpenStackネットワークと、あとはOpenStackネットワークとアタッチするアディショナルなネットワークサービスというポイントで話すときは、突然英語でしゃべる状態になります。
よくわからない英語を、たくさんがんばって1時間くらいしゃべる感じでやっていると思います。なのでアレルギーはないほうがいいかなと思いますね。
早川:通訳さんも一応いらっしゃるので。
城倉:そうですね。それ言っていなかった。ものすごく大規模で優秀な通訳チームがいます。たぶん、このセッションもものすごい勢いで英語に通訳していただいていると思いますけど、そういう通訳チームがいます。もちろん通訳の方たちのタイムスロットを予約して、ミーティングごとにインバイトしたりだとか。そういった文化はよくできています。
社内は英語と韓国語と日本語で回っていて、我々のチームやディビジョンはSlackで主な連絡をしていることが多いです。そこにも翻訳botがいて、よしなにほんやくコンニャクしてくれるという感じですね。
あと、大学生のためのオープンインターンシップもやっています。たぶんインターナショナルにオープンしているはずです。年に1回か2回くらいあって、数ヶ月スパンでやっているかと思います
城倉:では、次のところに入りましょう。みなさんが業務でやっている技術的なアドバンテージとそのイシュー、課題感みたいなものを軽く教えてください。早川さんはどうですか?
早川:アドバンテージとはどういう感じなんでしたっけ?
城倉:例えば、「私はシステムソフトウェアのデバックがめちゃくちゃ得意です」みたいな。なんでもいいんですよ。背が高い、顔がかっこいいとか、なんでもいいです。
早川:自分の強みって話ですね。
城倉:そうですね。インフラストラクチャーのデベロップメントチームのアドバンテージでもよいと思います。このへんはMCの僕が適当なところもあってフワフワですが、アドバンテージにかかっていることだったら、なんでもいいです。
早川:なるほど。僕は実際に職業エンジニアとしての能力がたぶんほとんどない中で、なんとかこの職に滑り込むことができたのは、わりとすごくニッチなところだけ自分は得意なところがあります。とりわけシステムソフトウェアのデバックなど、内部構造のようなものに多少詳しいんですよね。
LINEのロードバランサは内製で100パーセント作っています。どこまで内製で作っているかと言うと、実際にユーザーのトラフィックをさばく、ネットワーク用語で言うとデータプレーンまで全部ソフトウェアで自作しているんですよね。
そのデータプレーンレイヤーになるとニッチな領域になってきて、カーネルやバケット処理の知識などが要求されるようなところがあります。システムプログラミングティックな領域になってくるんですよね。
そういうところになんとかして強みを持って入ってこれたところはありますね。こういう領域を業務として触れる職種って、そんなにたくさんはないと思います。日本国内に限る話かもしれません。
たぶん、そういうところはほとんどの人が自分たちで使う側なんですよね。でも、作る側になれるのは、とりわけネットワーク開発チームの仕事だと、そういうところが多いんですかね。システムプログラミングな領域に関われることが、この職の大きなアドバンテージなんじゃないのかなと思いますね。
城倉:そうですね。
早川:インフラエンジニアの中でもなかなかないんじゃないですか?
城倉:たしかに。インフラを持ってて、その上にいろいろワークロードがあって、そのインフラを手を加えて作っていることが重要なポイントだと思いました。
内海さんのOslo Metricsも、LINEのOpenStackのスケーラビリティはものすごく大きいほうだと思います。OpenStackのスケーラビリティがあるから、しっかり調べないといけないんですよね。
Reliability Engineeringが肝になってくるフェーズに、だいぶ前から突入していると思います。そういったことがあるからそういう仕事ができていて、それぞれの技術的なスペシャリティをよく活かせているのが、我々のアドバンテージだと思いますね。
城倉:みなさんの中で「ここが俺の課題だな」「チームの課題だな」「Verdaの課題だな」みたいなことを思ったりますか?
僕的に思うのは、我々は大きなソフトウェアをマネージしたり、作ったりというのを回せている反面、自分たちで作ったソフトウェアの管理コストみたいなものが最近少しずつ高くなってきているかなぁと思いますね。
僕はLBに被っていないので言えるんですけど、LBもけっこう前から作っていて、すでにだいぶ運用実績があると思います。人の入れ替えがもう少しあっても、きれいに回るようにしていくエンジニアリングもあるかなとは思いますね。
ちょうどコミュニケーションで難しいと感じる点に関しては、英語ができない僕からすると、がんばって英語で説明したり、英語で聞くポイントで課題感はあると思います。みんなが余裕を持って聞いてくれるので、そのへんはモチベーションとパッション次第かなとは思っています。
英語得意勢は、コミュニケーション課題はありますか? たぶん、一番自由度が高い2人だと思う。
早川:いやいや(笑)。どうでしょう? 内海さん。
内海:そうですね。僕は基本的には、前職も英語で働いていたんですけど。正直、日本語のほうが楽だとは思っちゃいます。
城倉:そうなんですね。
内海:一応、確認することは気をつけてはいます。相手が言ったことで「たぶんこうだよね」で動いて、あとからそれが違って時間を無駄にはしたくないんですよね。明確に「こういうことだよね?」「これでいこうと思います」というコミュニケーションを取るようにはしていると思います。
城倉:なるほど、なるほど。
早川:インフラ固有の問題かはわからないですけど、英語だろうと日本語だろうと、運用上の都合やコンテキストみたいなものがあります。ほかのアプリの開発でも同じなのかな? コンテキストが大きくなりそうなので、会話がハイコンテキストになりがちですよね。そういうところを気をつけないと、たぶん新しく入ってきた人とかは大変なのかもしれないですね。
城倉:ありがとうございます。もう時間がほとんどありません。
早川:思ったより早いですね(笑)。
城倉:質問で「技術選定の際に気をつけていることはありますか?」。これは非常にいい質問な気がしてきた。なにかありますか? 少なくともオープンディスカッションに我々はしていると思います。
「こういうものでいこう」というコミュニケーションをとって、みんながVoteしたり、イチャモンつけたりしていますよね。また、「これはこっちのほうがいいだろう」とか、Pros/ConsのプロポーザルみたいなものをWikiで書いて、それをみんなで見たりしていると思います。
早川:この仕事をしていると、運用も気をつけて技術選定しないといけないと思いますね。あとから運用に載せることを見越して、けっこう長いスパンで運用することを留意したうえで技術選定しないと、あとから辛くなっちゃうんですよね。
城倉:そうですね。そういうことがけっこうあるかなと思います。
ちなみに、内海さんのOslo Metricsで別の方法はあったりしたんですか?
内海:正直、僕が入ってきたときには「こういう方向でいこう」というのは決まっていました。一応、過去の履歴を見ると、いろいろ議論されていましたね。
城倉:なるほど。オープンディスカッション系と、運用を見越していること。LBみたいにないから作ろうみたいなこともあるという感じですかね。
時間がもうなくなってしまったので、本日こんな感じなんですけれども(笑)。もし追加で気になることがあったら、いろいろカジュアル面談などできたりすると思います。
本日の我々のカジュアルセッションはこれで終わりにしたいと思います。短い時間でしたが、どうもありがとうございました。
LINE株式会社
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2024.12.19
12万通りの「資格の組み合わせ」の中で厳選された60の項目 532の資格を持つ林雄次氏の新刊『資格のかけ算』の見所
2024.12.16
32歳で成績最下位から1年でトップ営業になれた理由 売るテクニックよりも大事な「あり方」
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
2024.12.13
ファシリテーターは「しゃべらないほうがいい」理由 入山章栄氏が語る、心理的安全性の高い場を作るポイント
PR | 2024.12.20
モンスター化したExcelが、ある日突然崩壊 昭和のガス工事会社を生まれ変わらせた、起死回生のノーコード活用術
2024.12.18
「社長以外みんな儲かる給与設計」にした理由 経営者たちが語る、優秀な人材集め・会社を発展させるためのヒント
2024.12.12
今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは
PR | 2024.11.26
なぜ電話営業はなくならない?その要因は「属人化」 通話内容をデータ化するZoomのクラウドサービス活用術
Climbers Startup JAPAN EXPO 2024 - 秋 -
2024.11.20 - 2024.11.21
『主体的なキャリア形成』を考える~資格のかけ算について〜
2024.12.07 - 2024.12.07
Startup CTO of the year 2024
2024.11.19 - 2024.11.19
社員の力を引き出す経営戦略〜ひとり一人が自ら成長する組織づくり〜
2024.11.20 - 2024.11.20
「確率思考」で未来を見通す 事業を成功に導く意思決定 ~エビデンス・ベースド・マーケティング思考の調査分析で事業に有効な予測手法とは~
2024.11.05 - 2024.11.05