LINEの開発現場を支えるCI/CD　DevOps推進のために大切にしていること

LINEにおけるCI/CDとMonitoring

黒木亮太氏（以下、黒木）：「LINEにおけるCI/CDとMonitoring」というお話をさせていただこうかなと思ってます。

まずは私のプロフィールです。私は黒木亮太と言います。2019年にLINE Growth Technologyに移って、LINE Growth Technology株式会社の東京開発室の室長をやっています。

もともとWeb系の会社にずっといて、こういう業界にはけっこう長くいることもあり、さまざまな視点から見ているので、LINEの特殊なところがなんとなくわかっています。今日は「LINEならでは」のツールをどうやって使っているかを情報共有できたらなと思ってます。

今日のアジェンダなんですけど、まずはLINE Growth Technologyという会社自体をご存知の方はなかなかまだ少ないと思うので、最初にその紹介をさせていただいて、そのあとはCI/CDと、モニタリング・アラートについて大きく2つ紹介させていただきます。

まず最初のアジェンダにいきます。ちなみにLINE Growth Technologyを知っている方はどのくらいいますかね？

（会場挙手）

少ないですね。

会社名に「Growth」を冠する理由

実は今、会社説明会をしていて、Twitter Adでたまに見る人がいるかもしれないんですが、LINE Growth TechnologyはLINEの100パーセント子会社ですね。その中で開発組織として動いている立ち位置となっております。

LINEとどう違うのかは、会社名にある通りGrowthをテクノロジーで解決するところがミッションです。

ミッションとしては大きく2つですね。LINEのさまざまなサービスの成長と、それに関わる人の成長を我々はミッションとして置いています。

我々は「Growth開発」と呼んでいるのですが、なかなかこのGrowth開発は一般的な言葉ではないので補足させていただきます。

よく上がる質問としては「LINE側のサービスに関わる運用部分を担当するのではないか？」「Growth Hack専門のチームなのではないか？」と質問されるんですけど、ちょっと違います。

Growth Technologyは、LINEのサービスの成長を担う開発組織となっていて、LINEのいち開発組織の立ち位置で開発を行っていきます。

領域としては大きく2つ持っていて、いわゆるエンドユーザが使うサービスについて、UI/UX含めてサービスの満足度や認知度の改善に貢献するような開発を行っています。

もう1つの領域としては、運営改善です。Webサービスはリリースして終わりじゃなくて、そこから何年も運用・運営をしていくので、そういうところでしっかり運営の品質を向上させることが、すごく大事なミッションです。

例えば、サービスをリリースしてユーザー拡大をしているときに、運営フローなどの問題で詰まってしまってはせっかくのプロモーションも最大限の効果を得られません。そのような事が起きないように、運営フローやそれに関わるシステムの改善や開発をしています。

まとめると、1つはLINEのいち開発組織であることと、使っている技術はLINEと同水準で開発を行っています。これは技術、言語もそうですし、今のLINEだとインフラは社内のプライベートクラウドで成り立っているんですけど、そういったインフラや、その上に乗っているアーキテクチャ、ミドルウェアも同じような水準で使っています。

その中でGrowth開発を専門領域とするチームだと認識していただければなと思います。ぜひとも一人でも多くの方にLINE Growth Technologyを知っていただきたいです。

今日のこれ以降のプレゼンは一応LINE Growth Technologyの業務軸での話となっています。LINEはグループ全体でさまざまな組織とさまざまなサービスを運営しているので、必ずしも同様ではないことだけ最初にお伝えいたします。

CI/CDとモニタリングはどう成り立っているか

ここからは、CI/CDやモニタリング、アラートがどう成り立っているのかをお話させていただきます。

まずはCI/CDからですね。CI/CDのツールでいうと、みなさんもいろいろ使われていると思うんですけど、代表的なものを列挙しました。JenkinsやCircleCIなど、最近だとDroneを使っている会社さんも多いかなと思います。一番下にPMCと書かれているんですけど、こちらはLINE内製のCI/CDを行うツールです。このあたりは独特なので後述させていただきます。

今日は基本的にはこの下の2つについてお話しします。なぜPMCを作っているかというと、一言でいうと標準化です。PMCでは操作ログなどをLINEで定めた基準で蓄積しています。それにより、例えば「このサービスはログが残ってない」「必要なときに見れない」ということを解決しています。

そのため、LINEではデプロイ時にPMCを利用しているサービスが多いです。

パターンで言うと、スライド左側はみなさんもよく使われているおじさんですね。Jenkinsを使って、ビルドした生成ファイルを社内のリポジトリに入れて、あとはデプロイするときに先ほどのPMCを使って、そこの履歴管理を行いつつCDを行っているのが1つのパターンです。

そのPMCの課題は、やはり最近コンテナの利用が多くなってくる中で、その対応が必要になってきます。先ほどのツールはまだ実はコンテナ対応できてなかったりするので、その対応が必要です。あとはそもそもそのPMCに頼らないで他の代替手段を使う検討も始めないといけないですね。

そこで、我々が次にどういう技術を使っていこうかと話したときに、Droneというアイデアが出ました。今は実用化に向けた試みを実施中で、まだプロダクションで利用はしてはないんですけど、検証段階です。

なぜDroneを利用するのかと言うと、まず1つはDockerネイティブであるところと、あとはスケールメリットですね。コンテナなので、そこの並列処理とかで高速に実行可能です。ビルドとかテストが高速にできるというのと、あとは実は社内に全社が使えるDrone環境が用意されていて、それで導入ハードルが下がっているのが1つあります。

今やっているところで言うと、先ほどJenkinsを置いていたところにとりあえず置き換えることによって、テストとかビルドを高速化する動きですね。置き換えることでけっこう簡単にできるので動いています。Droneを使ってプライベートリポジトリはHarborを使って、そこに入っているファイルをPMCでサービスにデプロイする。

ただ、これだと先ほどの課題が解決されないので、ここからCDの部分をどうしていくかみたいなところを考えています。例えば、Argo CDとKubernetesを連携させてデプロイするとか。このへんは今後一般的になっていくと思うので、その取り組みも内部で行っています。ただ、やはり先ほどのLINEで定めた基準などをクリアする必要はあり、まだいくつかのハードルを乗り越えてやっと使える感じですね。なので、このへんはまた次の機会にでも詳しく共有できたらなと思っています。

Growthの職種とモニタリングについて

次がモニタリングの話になるんですが、次のアジェンダに行く前に職種の話を少しさせていただければなと思います。

LINE Growth Technologyではエンジニアの職種が3つあって、サーバーサイドとフロントエンドと開発支援というロールがあります。この開発支援はいわゆるサービス開発における支援ツールの開発などと、SREのような動きをするチームになっています。

職種とカバー範囲を図にしてみました。インフラはVerdaと呼ばれるプライベートクラウドを使っていて、インフラチームが管理しています。その上に乗っているアプリケーション・ミドルウェアが我々アプリケーションエンジニアの範囲になるんですけど、その中でもサーバーサイドとフロントエンドエンジニアは、アプリケーションの部分とミドルウェアですね。

開発支援はミドルウェアのチューニングなどでサポートしてくれたり、あとは開発を効率よく行うために必要するための支援ツールにフォーカスしたチームになっています。モニタリングでいうと、ここの開発支援ツールがうちの社内で重要になってきているので、そこの紹介をさせていただこうと思っています。

モニタリングとアラートですね。モニタリングに関しては先ほどヤプリさんのところでDatadogもあったと思いますが、他にも例えばZabbixやPrometheusを使っています。今日は多くは触れませんが、モニタリングツールについても一番下は内製のものです。

今日は我々もよく使っているPrometheusというツールを深掘って話そうと思います。

LINEでは、モニタリングのところでPrometheusを多く使っています。その下にPromgenという文字がありますが、これはLINEでオープンソースで公開しているツールになります。

Promgenは、Prometheusをアプリケーションエンジニアが利用しやすくすることが目的のツールです。機能としてはPrometheusの設定ファイルの作成と管理、あとはアラートの通知と構成管理などができます。もし近いようなことを考えてる方がいらっしゃればぜひGithubで見ていただければと思っています。

また、LINEのEngineering Blogで書いていたり、あとは2015年のLINE DEVELOPER DAYの資料がWebにあるので興味ある人は見てください。

Promgenを大きく3つに切り出す

Promgenがどういうことをやっているかをご紹介します。Demo Serviceというサンプルを持ってきているんですけど、基本的な構成はRulesとSenderと、Projectsに大きく切られています。

Rulesはモニタリングのルールを設定するところです。基本最低限のルールはデフォルトで用意はされているものの、用途によって変更可能です。例えば、Hadoopクラスタを持っていたりすると、CPUの細かい監視を切りたいこともあると思います。他にもサービス特性によってモニタリングをする・しないのはもちろんあると思うので、そういうところはサービス側でカスタマイズする方針です。

モニタリングをする・しないのOn/Offもそうですし、閾値やルール自体のオーバーライドみたいなところもこの設定で行うことができます。

Senderは通知の設定ですね。先ほどのモニタリングのところで閾値とか、どういうものを監視するかを決めるんですが、それらが閾値を超えた場合にアラートをどこに通知するかをここで設定しています。

利用できる通知の種類もいくつか用意されています。LINE社内ではSlackに連携することが多いですが、他にも、メールやLINE、Webhookを利用して他のツールと連携させるところもカスタマイズできるようになっています。

最後にProjectsはいわゆるグループの設定ですね。例えばWebサーバーであったりとか、APIサーバーやバッチサーバーみたいなそういう役割があると思うので、それらをこのプロジェクト単位で切ってもらって、Webサーバーに必要なエクスポーターなどの監視の閾値をグループ単位で設定することができます。

こういったものを作ることによって何がうれしいかと言うと、Prometheusをそのまま使うとなると、先ほどのアプリケーションエンジニアだと設定のハードルが高かったりするので、そういうところを補うために作っているツールになります。

なので基本的にはアプリケーションエンジニアがこの辺の設定をして、監視、モニタリング、アラートの設定までは簡単にできるようなサポートツールとして開発支援のメンバーが動いているというかたちですね。

ここまでがPromgenの説明なんですけど、他に先ほどのチームがけっこう便利なツールとして作っているものがいくつかあるので、その考え方とかこういうものを作ってますよみたいな紹介です。

その他の便利ツール

1つ目は、リポジトリ管理です。社内用のAnsible Galaxy用のリポジトリを用意しています。管理の対象としてはPrometheusを利用する際のエクスポーターや各種ミドルウェアです。

これらをAnsibleのアプリケーション側で設定することによって、さきほど標準的なところがデフォルトで入るので、あとはそのサービス特性に応じたカスタマイズはアプリケーション側で実施するかたちですね。

もう1つが、アラートの詳細情報をSlackに通知してくれるBotです。

アラートが来て「どこが原因なんだ？」みたいなところを探るときに、実際のモニタリングツールにログインして確認、というのがけっこう多いと思うんですが、そうするとコミュニケーションがその場で完結しなかったり、見るところが人によって違ったりするので、最低限見るべきところをある程度アラートのタイミングでBotで連携しています。

このツールで特徴的なのは、情報がSlackに来るのもそうなんですが、「これは別にいいよ」というものはSlack上でサイレンス設定にすることができるところです。また、スレッド内にモニタリンググラフをキャプチャで貼っていってくれるので、ある程度どのへんが原因でこのアラートが起きているかをSlackのコミュニティ上で完結できるのも1つの特徴ですね。

このような支援は、我々のところだと明確なロールがありますが、そのような事もアプリケーション開発を効率に行うための1つの手段かなと思っています。

あとは最後に、我々も設立して1年半ですが、まだまだ一緒に開発チームとして活躍してくれるメンバーを募集しているので、もし興味があれば声を掛けてください。

ご清聴ありがとうございました。

司会者：ありがとうございました！　黒木さんありがとうございます！

（会場拍手）