この記事は LINE Advent Calendar2016 の 3 日目の記事です。 はじめに はじめまして、LINEの@huydxです。現在「Engineering Efficiency」というかっこいい名前のチームに配属されています。日常の仕事では、社内のモニタリングミドルウェア、自動化ツールの開発などにおいて、主にバックエンド側を担当しています。エンジニアリングで組織全体の生産性と幸せを向上することです。この記事では、チームの取り組み、そして個人的な気づきなどを紹介させていただきます。 背景 現在私が所属している部署はLINEメッセージのバックエンド側を担当しています。システムの規模が大きくなるとともに、組織全体も大きくなる一方です。ソフトウェアのスケールはもちろん難しいですが、組織のスケールも簡単なことではありません。 もちろん、体制、マネージメントなどで頑張って、組織を小さく分割するなどの方向で進むところもあります。ですが、LINEメッセージプラットフォームの特徴として、モノリシックな「Talk-server」という巨大なJavaアプリが中心に存在し、たくさんの開発者がそこに毎日コントリビュートしています。そこで、効率良く安全にLINEメッセージ基盤を提供するためどうしてもマネージメントだけでは無理なところがあって、そこでちゃんとエンジニアリングで解決できるものを解決し、エンジニアたちが安心して効率よくパフォーマンスを出るようにするのが私のチームのミッションのひとつです。 基本の解決方針としては Painful Pointを発見して、自動化できる（また自動化すべき）ところを自動化する 新しい技術、ベストプラクティスを導入することによりプロセスを改善する 良いモニタリングシステムと良いデプロイシステムを提供することで、より早く、安全でソフトウェアを開発を進むことを可能にする その方針に沿って、最近の取り組みや気づきを簡単に紹介します。 プロセスをコードで表現 現在の部署では多くの人々がいくつかのメインリポジトリで毎日開発を進めています。大人数のエンジニアがお互いに何をしているかを把握しないと混乱が発生してしまうので、ちゃんと定義したプロセスとコンベンションに従わないといけない。そのプロセスは一昨年のブログで紹介されていますので、是非ご覧ください。記事を読んでみると分かると思いますが、フォローするのはなかなか大変です。ただ大変とはいえ、LINEのようなプラットフォームでは、安全にソフトウェアをリリースするために欠かせないプロセスとなります。 その大変さをどうやって解消するか工夫していて、最近の取り組みのひとつとして「Process As A Code」という概念を私が独自に定義しました。つまり、プロセスそのものを全部コードで表現して、表現したものをツールとして実装すれば、エンジニアが手軽にプロセスをフォローすることができ、ストレスも解消できると考えます。ツールはすごく簡単なコンマンドラインツールで、使い方も日常よく使われているコンセプトに基づいて気軽に使えます。 $lineflow talk-server Usage: lineflow talk-server new-develop-branch <BTS-ID> lineflow talk-server develop-pull-request [--skip-mvn-test] lineflow talk-server commit [--add-all] [--no-issue] [--squash] <message> lineflow talk-server release-cherry-pick lineflow talk-server release-pull-request [--skip-mvn-test] lineflow talk-server rc-create [--push-new] lineflow talk-server version-commit [--increase-patch] [--increase-minor] [--increase-major] <version> ツールの中でJIRA, GitHub Enterprise, 社内のデプロイシステムを全部連携して、自動化できるところを全部自動化し、また、過去のコマンドをヒストリーファイルに保存して、「次にどのコマンドを打てば良いか」を推薦する機能なども開発しています。新しいプロセスを追加するとき、またはコンベンションを変えるときには、コードにそれを反映して、チーム全員がツールの最新バージョンを更新すれば同じコンベンションをフォローできますよね。新しいメンバーが入るときに、ややこしいプロセスに邪魔されず、すぐに開発を進めることも期待できます。 社内ツールを作るときの考え方 現在、チームが開発しているソフトウェアは「社内ツール」と呼ばれていますが、「社内ツール」には特にAPIとか認証とかいらないなというイメージを持っている方が多いと思います。しかしながら、私たちの考えは社内ツールだからこそ以下の性質を持たないといけないと考えています。 使いやすいAPIを提供する 認証ができ、監査がしやすい状態にする コード品質とプロダクトの方針を明確に定義する ドキュメントを充実させる まずAPIさえあれば、チーム内のコラボレーションがやりやすくなり、ユーザ（開発者）自身による自発的なツール開発もできます。逆に APIがないと、直接DBを接続して変更したりすることになりうるので結合度が密になって変更しづらくなってしまい、システムが更新できなくなります。APIは基本的なHTTPのRESTで設計されいるので簡単にcurlを使ってテストができ、また、手軽にswaggerなどを使ってウェブUIで使い方などを確認できます。 認証についてですが、大人数が同じリポジトリを触っていて、同じサーバクラスターにデプロイするので、安全性を保つためには、「誰が何をできる」かをちゃんと認可(Authorize)できることが要求されます。そこで、現在のチームではOAuthベースの認証システムを開発しており、基本的な操作はウェブUI、あるいはトークンベース認証のAPIを通じて操作するので、全部の操作はログで残していて、なにかある場合はトラブルシューティングがしやすいです。 社内ツールというのは、短期的な目的に対しての簡単なハックかスクリプトになりがちでしょう。ただそうなると、大きい組織全体にはスケールできず、要求の変更によるメンテナンスがしづらいので、費用対効果は良くありません。なので、最初からツールの目的、使えるスコープ、利用シナリオなどをちゃんと考慮して開発しないといけません。また、オープンソースに向けて開発を進めるのが一番オススメです。 最後に、社内ツールだからこそドキュメントはエンドユーザ向けのアプリケーションよりも充実しないといけないません。ドキュメントが足りないと、誰も使ってくれませんし、逆にドキュメントが充実していればユーザから積極的にコントリビュートしてくれるでしょう。良いドキュメントであるためには、ちゃんと以下の項目が存在すれば良いと思います。 ツールを作った背景 ツールのアーキテクチャ どうやってコントリビュートするのかを明確に書く 社内開発をやるか、あるいはオープンソースを利用するのか 現在のチームでは、モニタリングツール、デプロイツールなどを全部自社で開発しています。なぜオープンソースが使われていないか、という疑問を持っている方もいると思います。もちろん、オープンソースで使えるところでは積極的にJenkinsなどのオープンソースを使っていますが、LINEのスケールに合わない、過去の経緯やインフラストラクチャーの構成に合わない、またはセキュリティなど色々な問題に囲まれて、オープンソースがフィットしない場面もあります。 その時はちゃんと開発リソースを確保して開発しないとLINE本体のシステムに影響がでてしまうこともあります。一方で、社内の開発だけに頼ると、現在の技術トレンドやベストプラクティスに追いつくのが大変ですので、両方をうまく組み合わせるのがベストです。 最近の取り組みのひとつを紹介します。現在社内のモニタリングシステムが自社で開発されて、IMONというシステムを担当しています。IMONはデータ収集、チャートの表示、アラート・ノーティフィケーション管理などを全部含めるAll-In-Oneのシステムで結構便利に使えるシステムです。 ですが、いままでのユーザが毎日見ないといけないIMONのチャート表示機能は簡単なチャートしか表示できていません。豊かなダッシュボードを作りたい、アノテーション機能ほしい、テンプレート機能ほしいなど様々なユーザからたくさんの要求があり、その機能を全部ちゃんとサポートするのはかなり時間がかかるし、工数もすごいかかる見込みなのでGrafanaを利用することを選択しました。 IMONのデータソースを開発し、Grafanaにグラフ表示とダッシュボード作成などを任せることにしました。これにより、Grafanaに慣れている多くの開発者にとって使いやすくなり、Grafanaのたくさんの機能を流用することも可能になって、工数の削減もできてとてもよかったと感じていました。今後私たちのチームもフィットするところを探して積極的にオープンソースなども導入する方針を進めていきます。 結論 話が長くなってしまいましたが、現在のチームでは、エンジニアのためのものづくりで毎日楽しくソフトウェア開発ができています。グロバールサービスで使われている最高のモニタリングシステム、便利なデプロイシステム、そしてエンジニアの幸せを向上するさまざまなシステムを開発するエンジニアを積極的に募集しています。 https://linecorp.com/ja/career/position/664 明日はMasakuniさんによる「toLowerCaseの落とし穴とCase Foldingの話」についての記事です。お楽しみに！
↧