![[社員インタビュー] Vol.20 大規模サービスの信頼性向上に取り組むSRE サムネイル画像](https://blog.lycomm.co.jp/hubfs/Imported_Blog_Media/b0eddb24.jpg)
こんにちは。採用担当の光田です。
LINEには、サービスの信頼性向上に向けた取り組みを専任で担うSRE（Site Reliability Engineer）が在籍しています。会社やサービスの規模などによりSREの領域は様々。今回はエンジニアの松崎にLINE FukuokaのSREの働き方について聞きました。
ーこれまでのキャリアを教えてください
元々、LINEのエンジニア達がブログやコミュニティイベントで発信していた情報に興味を持っていた事もあり、入社を決めました。
LINEには、サービスの信頼性向上に向けた取り組みを専任で担うSRE（Site Reliability Engineer）が在籍しています。会社やサービスの規模などによりSREの領域は様々。今回はエンジニアの松崎にLINE FukuokaのSREの働き方について聞きました。
圧倒的な実力の差が入社を決めたきっかけ
ーこれまでのキャリアを教えてください
新卒でSESとしてエンジニアキャリアをスタートし、ERP開発（基幹系業務システム）の会社で経験を積んだのち、LINE Fukuokaに入社しました。これまで業務システム開発に携わる中で、設計・開発・運用(インフラ/サーバー/ミドルウェア)と幅広い領域を経験してきました。
ー入社したきっかけを教えてください
きっかけはいくつかありますが、その1つは「ISUCON（Iikanjini Speed Up Contest）」というコンテストです。ISUCONはWebサービスを決められたレギュレーションの中で限界まで高速化を図るチューニングバトルで、界隈で有名なエンジニアが沢山参加されています。
前職の時に知人のエンジニアや当時の同僚と参加しましたが、毎回全然だめで圧倒的な実力の差を感じ、エンジニアとしてもっと成長するために技術的な要求が高くてレベルが高いエンジニアが多数いる環境で働きたいと思うようになりました。
元々、LINEのエンジニア達がブログやコミュニティイベントで発信していた情報に興味を持っていた事もあり、入社を決めました。
SREの担当領域は広くて深い
－業務内容を教えてください
－業務内容を教えてください
LINE Shop （LINEサービスにおける、スタンプ・絵文字・着せかえなどのコンテンツを利用・販売するためのプラットフォーム）にSREとして携わっています。
チームの体制は、開発エンジニアが福岡と東京でそれぞれ約10名ずつ。SREはチームに私1名です。SREの担当範囲は会社やサービスのフェーズ、開発体制によって様々だと思いますが、私はサービスの可用性・パフォーマンスなどに責任を持つのがSREだと考えています。
そのためのコードを書いたり、モニタリング、キャパシティプランニング、サーバー運用、ミドルウェア運用などをチームメンバーや関係する他のチーム（インフラエンジニア、DBAなど）と一緒に取り組んでいます。
チームの体制は、開発エンジニアが福岡と東京でそれぞれ約10名ずつ。SREはチームに私1名です。SREの担当範囲は会社やサービスのフェーズ、開発体制によって様々だと思いますが、私はサービスの可用性・パフォーマンスなどに責任を持つのがSREだと考えています。
そのためのコードを書いたり、モニタリング、キャパシティプランニング、サーバー運用、ミドルウェア運用などをチームメンバーや関係する他のチーム（インフラエンジニア、DBAなど）と一緒に取り組んでいます。
直近では、Elasticsearch関連のパフォーマンス改善のため、ロジックの改修、クライアントライブラリの移行、Elasticsearchのチューニングなどを行っています。
あと、SREのプラクティスにポストモーテムがありますが、これは私たちのサービスだけではなく会社全体で取り組んでいます。インシデントが発生したら、そのインパクトや根本原因の調査、再発防止・改善のためのアクションプランなどをまとめてステークホルダーに共有、ミーティングにて詳細の確認を行います。
ーLINE Shop のSREの面白みは？
スタンプや絵文字でのコミュニケーションはLINEの特徴かつ重要な機能の1つだと思います。
私自身、家族や友人とのLINEのやり取りでスタンプや絵文字でを頻繁に使っていますし、海外のエンジニア向けカンファレンスに行った時に、LINEのスタンプを使ってくれている海外ユーザーに会った事もありました。国内で誰もが知っていて、海外も含めて本当に沢山のユーザーに使ってもらえるサービスに携われるのは嬉しいです。
また、それだけ沢山の人に使って頂いてるので、サービスのトラフィックもかなり多いです。
普段だとピーク時5万リクエスト/sec、イベントや年始の時は10万リクエスト/secくらいのトラフィックがあり、1日あたり平均4億3,300万回（2019年4月時点）ものスタンプが送信されています。
カスタムスタンプやLINEスタンプ プレミアムのような新サービスのリリースがあるたびにトラフィックは更に増えていくので、他のメンバーと一緒にサービスのリライアビリティに取り組んでいくのは、とてもチャレンジングで楽しいです。
LINEは規模が大きいのでエンジニアのロールも細分化されており、それぞれの分野にスペシャリストがいます。インフラエンジニアやDBAと連携して一緒にタスクを進行する場面も多いです。技術的な知識をもってコミュニケーションを取る必要があるため一定の難しさはありますが、それぞれの分野のプロフェッショナルと仕事をすることで自分の幅を広げられる機会になります。
大規模サービスでSREに取り組む
ーどんなエンジニアと一緒に働きたいですか？
高トラフィックなサービスを安定稼働させるという事にチャレンジしたい人と一緒に働きたいです。ISUCONが好きな人や、Javaで高トラフィックなサービスに携わりたい人は楽しんでもらえると思います。私たちのサービスはLINEが開発してOSSとしてGitHubで公開しているArmeriaやCentral Dogmaを用いてJavaで実装しています。
ー今後取り組みたいチャレンジを教えてください。
SREのプラクティスの中で最も重要なものの1つにSLI（Service Level Indicator）とSLO（Service Level Objective）というものがあります。SLIはサービスの安定性を測るための指標で、SLOは各SLIに対する目標数値です。
以前にいくつかのメトリックをSLIとして、SLOを可視化するということをやってみたのですが、今後は開発エンジニアだけでなく他のステークホルダーと一緒にSLOとしてきちんと策定し、運用していきたいです。
あと時期によっては、運用作業の割合がものすごく増えてしまい、SREとして本来やりたいサービス安定化のための作業や運用の省力化のための自動化などに時間が取れない時があるので、常にそれぞれをバランス良く進めたいと思っています。運用作業と SREとして本来やりたい事の割合は、出来れば50:50くらいにしたいですね。
また、サービスの仕様やコードの知識をもっと深めたいと思っています。
サービス障害があった時に問題を解決するためには、コードを読む必要がありますし、サービスの仕様がわかっていないと改善も難しいです。数ヶ月前に久しぶりにサービスの機能実装を少しだけやったのですが、やはり仕様やコードの知識を増やすには自分で実装するのが一番だなと思いました。
個人的なエンジニアリングの観点では、コードを書く力を落とさないようしたり、進化し続けるJavaのキャッチアップすることはもちろん、サービスのミドルウェアももっと深堀りしていきたい思っています。それぞれの分野でプロフェッショナルがいる環境ではありますが、サービスを安定稼働させるには総合的な知識が必要だと思っています。
LINE Fukuokaでは福岡からWOWを生み出すべく、共にチャレンジする仲間を募集しています。
今回インタビューをした開発室の募集ポジションはこちらからご覧ください。
▼開発 募集要項
▼SRE（コンテンツ販売プラットフォーム）
＃開発室 にご興味をお持ちなら、この記事もおススメ！
LINE Fukuokaの採用情報や各種取り組みについては、下記の公式アカウントから随時お届けいたします。是非ご登録ください。
LINE公式アカウント （LINE ID：@linefukuoka）
