LINEが注力している「銀行事業」「LINE証券」「LINE Pay」のフロントエンドエンジニアと裏方・SREは何をしているのか

LINE FintechサービスのSRE

国兼周平氏（以下、国兼）： SREチームの国兼と申します。前職はSierにいまして、金融とか公共の大小さまざまな案件を中心にいろいろ経験しました。実は前職でも証券も銀行もやったことがあります。

2018年にLINEに入社しまして、当初はLINEマンガとか、どちらかというとエンターテインメント寄りのサービスをやってみたいなと思っていました。しかし、前職で金融分野の経験がそれなりにあったということもあり、入社承諾後に熱くフィナンシャルのほうに誘っていただき、最終的には心が動いてフィナンシャル開発センターにJOINしました。気付いたら今はフィナンシャルのSREという、想像もしていなかったようなポジションにいます。

SREチームは技術的にサポートしなければいけない範囲が広い

フィナンシャルSREチームは、LINEの提供する金融サービスのうち証券と銀行をサポートしていて、それらのサービスの信頼性・品質の向上もしくは維持を目的に活動しています。ちょっとぼんやりした言い方になりましたが、簡単に言うと必要なサービスを必要なときに十分な性能で提供し続けるというのが一番大事な仕事になります。

プロダクトの機能そのものの開発には直接参加しないので裏方といえば裏方なのですが、非常にいろいろなエンジニアに頼られるので、やりがいのあるポジションだと思っています。技術的なことだけではなく、人が運用する部分の業務改善なども手掛けています。

私たちのサポートするLINEの金融サービスでは、情報の機密性を守らなくてはならない、他の事業からのサイドエフェクトを防止しなくてはならない、ということをとても強く意識しており、非常に多くの部分でオンプレミスなインフラを使っています。独自にデータセンターを用意してネットワークやサーバーを構築し、その上にいろいろなサービスを動かしているということになります。

そのため私たちのSREチームは、パブリッククラウドや社内共通基盤をメインに使っているようなSREチームに比べて技術的にサポートしなければいけない範囲が広く、仕事の量も実際に多いと思っています。

運用課題の可視化、スケーリング、自動化への取り組み

具体的な役割についてですが、まず1つ目が運用課題の可視化です。メトリクスやログなど、システムの状態を表すさまざまな情報を収集して、複雑なシステムの中のどこで何が起きているのか、今後問題が発生する予兆がないか、といったことを把握できるような環境を構築したり運用したりします。

だんだんサービスが大きくなってくると本当にどこで何が起きているかがわかりづらくなってくるので、簡単に把握できるような環境をつくらないと、改善していくこともできないということですね。そうやって把握できた課題、もしくは実際に開発をしているエンジニアや運用担当者などから上がってきた課題に対して具体的に解決策を検討して実施していきます。

よくあるのがスケーリングやチューニングといった性能改善です。ユーザーが増えたりサービスの種類が増えたりしてくると、だいたいどこかのポイントが辛くなってきているという予兆が出てくるので、問題が起こる前に増強して対応します。予想より早く性能が悪化しているような不自然な状況であれば、アプリケーションコードやミドルウェアの設定に不適切な箇所があるかもしれないので、確認してチューニングします。

テレビなどのメディアで紹介されて予想以上にたくさんのユーザーが見に来てくれたりすると、予兆なしで一瞬でピンチになって緊急対応というケースも稀にあります。

あとは人の手がかかってしまっているようなところを適切に自動化するというのが、僕たちの仕事の中でも非常に重要なところです。人の手がかかるということは、それだけミスが生まれる可能性がありますし、リソースをそこに割かれると他の改善活動が制限されるので、非常に重要な仕事と思っています。

その他にも、事業部門やオペレーションチーム、PMなどといろいろなところと調整して運用の体制やルールの見直しにもダイレクトに関与していきます。

インフラの設計からアプリケーションの運用まで

それから、今まさに銀行の開業準備をしていますが、新しい事業の立ち上げや大小さまざまな新しい機能を追加していくときに、新しいインフラが必要になります。そういったところを、より低いレイヤーを専門とするインフラチームと協力して、作り上げていきます。

次にアプリケーション配信／実行基盤の設計／構築／運用ですね。これはアプリケーションをデプロイしたりする部分をうまく抽象化・自動化して、便利にミスなく運用できるような環境を構築・運用していきます。それを開発者たちが利用するときの導入支援も実施します。

より適切に自動化された新しい基盤を開発し導入したときに、一気にすべてが移行できるわけではないので、古いものは常にある程度残ってしまいます。そういったものを放置せず徐々に移行していきます。

あとは、性能やセキュリティといった非機能まわりで出てくるような障害、もしくは原因がわかりにくい複雑な障害に関しては、私たちSREが中心になって調査し改善策を検討します。障害対応で重要なのは、既存のユーザーに対してどんな影響が出てきたかを突き詰めて事業に報告するところで、一番スピードが要求されます。そのあとに原因究明や改善の対応をします。

急速に立ち上がった部門がもつさまざまな弊害

私たちがサポートしている事業は証券と銀行業務の2つなのですが、証券は今どんな感じかと言いますと、去年（2019年）の8月にサービスを開始して、そのあと次々とサービスの種類や商品、機能を追加し続けています。

ユーザー数もおかげさまで伸びていまして、サービスの規模が拡大しています。マイクロサービスでやっているので、機能が増えるにつれサービスの数もどんどん増えていって、やっぱり運用をどれだけ簡単にしていくかが非常に重要になってきています。

LINE証券のアプリケーションの配信／実行基盤については、インフラ上の制限もあり、LINEがもっているさまざまな基盤の中でも少し古いタイプのものを採用せざるを得なかったという経緯があります。

そのあとに私たちは「これでは運用キツイ」ということで、新しい基盤を作り、今は新旧の両方の基盤が共存している状態になっています。徐々に旧基盤に載っているものを新基盤に移し替えているという状況です。

旧基盤というのは、サーバーの上で直接アプリケーションのバイナリを起動していて、それをしているが故に、サーバーは特定のアプリケーション専用のものとなりがちで、リソースを有効活用しにくい環境です。

デプロイの処理は職人芸みたいなShell Scriptの塊になっていて、新参者が扱うにはとても辛いものです。しかし私たちフィナンシャル開発センターというのは急速に立ち上がった部門なので、とくにLINE証券開業当初はまだ社歴の短い人が多く、この運用コストが大きな問題になっていました。

またアプリケーションとインフラ部分の境界が曖昧なところがあって、本来アプリケーションの開発に集中してほしい人が、インフラのところまで一部サポートしなければいけないというような弊害がありました。

解決するために新基盤を作った

こういった問題を解決するために私たちが作った新基盤は、まずアプリケーションをすべてコンテナ化するという前提で、サーバーが特定のアプリケーションに占有されずにリソースを効率的に使用できるような仕組みとし、デプロイのために準備するのはいくつかのシンプルな定義ファイルのみとしました。

そこからもうちょっとがんばって、サービスメッシュやAPI Gatewayなどを導入して、流量の制御や共通処理など、いろいろなことが柔軟にできるようにしています。それからログ・メトリクス・分散トレーシングなどについて、基盤側の考慮をできるだけ開発者にさせないように境界を置いています。

もともとこういったものの導入を想定していなかったオンプレ基盤に途中から導入するということで、部分的にソフトに導入していけるような製品がいいな、ということで、HashiCorpさんのConsul・Nomadという製品を中心に据えてやっています。あとは最近流行っていますが、サービスメッシュを作るためにEnvoyというプロキシサーバーをいろいろなところで使っています。

この基盤については最近あちこちで発表しているので、もしよかったら以下の資料をご覧いただければと思います。

（スライドを示し）サービスメッシュはこんなかたちですね。サイドカーパターンでEnvoy同士が全体のルーティング情報を交換して、あまり人がそこを意識することなく業務トラフィックを流していく仕組みになっています。Consul、Nomadなどの連携の仕方、サービスディスカバリーの仕組みのところの例が説明されてます。

銀行事業について

銀行については、開業準備中のところなので、あまり詳しくお話しすることができません。証券での学びや成功体験を活かして、信頼性の高いサービスをゼロから作っていこうとしています。

証券は途中から新しい基盤を入れたことによって、今2つの基盤が共存して複雑になっている部分も正直ありますし、途中から入れることになった新基盤も「途中から」という制限の中で選択肢が狭くなってしまった部分もあるので、そういったことが起こらないように銀行のほうは、最初から考えられることは考慮して進めていこうという感じでやっています。

募集ポジションはどちらで採用されても同じチームへ

SREは、2つのポジションで募集をかけています。アプリケーションエンジニアとインフラエンジニアの2つで募集していますが、実はどちらで採用されても、同じ私のチームに入ることになります。なぜ2つに分けているかというと、サポートする技術の範囲がとても広いので、全部1つの募集で書いてしまうと、本当に「なんでもできる人」という募集になってしまうからです。

あまりメリハリがつかなくて、恐らくみなさんの得意分野とのマッチングが難しいんじゃないかなと思ったので、2つに分けてみました。

分かれていること自体は重要ではないので、例えば応募を検討するときに得意分野が一部アプリケーションに書いてあって、一部インフラのほうに書いてあって、どちらかいうと難しいけど、両方見るといけるかなという方もいると思います。そういう方はぜひ一度、人事に相談してもらえれば横断的に評価可能ですので、よろしくお願いいたします。

現在のメンバーと技術スタック

実際に今どんなメンバーがいるかというと、（スライドを示し）こんな感じの構成になっていて、チームとしては非常に広い範囲をサポートしますが、全員が全部できるというわけじゃないです。ただ、ここのOS/ミドルウェア/構成管理のところは、ほぼ全員がメインの仕事としてやることになります。ミドルウェアといってもいろいろ種類があるので、全員が全部ではないのですが、ここについてはある程度のスキルが要求されると思っています。

技術スタックですが、（スライドを示し）ご覧の通りです。アプリケーションの開発チームは、今はKotlinのSpring Bootをメインにサーバーのアプリケーションを開発していて、これらを載せる基盤を私たちは運用しているという状態です。Python・Go・Rubyはどちらかというと私たちSREが運用に関わる部分や基盤の細かいところでよく使っています。

（スライドを示し）監視／可視化はこの通りですね。全部いつも使っているわけじゃないですが、模索しながらいろいろなものを導入してみています。HashiCorp製の製品を証券のところで使っていますね。Docker・Envoy辺りは、銀行のほうでもうまく導入していきたいなと思っています。

サーバーのOSは基本的にCentOSで、Windows Serverも一部ありますが、これはどちらかというとバックオフィスのほうのサーバーのサポートとなります。DBはMySQLが多いです。CacheはRedis、ログなどは全文検索エンジンのElasticsearch、MQはKafka、この辺はLINEではよく使われているもので、私たちもメインで使っています。

銀行ではOracle DBが出てくることになりそうです。

その他のミドルウェアは、ネットワーク的なものが多いです。あとはシークレット管理にVaultを使っているのが特徴的なところかもしれません。構成管理はAnsibleをよく使っています。Ansible PlaybookをGUIでサービスとして提供する、AWXもよく使っています。

Hypervisorや仮想ネットワークのところでは、VMware製品を使います。

フィナンシャルSREで働くメリット

フィナンシャルSREで働くメリットを少し考えてみました。新しい技術を導入しようというときに、それほど抵抗する人はいません。その点はあまり心配することがないかなと思います。ただそういったものを導入するときは、しっかりと内容を理解して、激しいアップデート、BugFixや新機能に追従していく覚悟が必要にはなります。

それから私たちのSREチームは、いろいろなチームの人たちと直接交渉することが多いので、社内・社外問わず知り合いが増えて、顔が広くなります。うまく環境を作れば、成果が上げやすくなります。

非常に緊張感のある仕事がたまにあります。最近けっこう慣れてきましたが、私も最初のほうは手がすごく汗だらけになったりしました。あとで冷静になって考えると「あの作業はすごいことだったな」みたいなことがよくあります。

それから、自分のチーム内にいろいろな得意分野をもった人がいます。私は元々サーバーアプリケーションの開発者なので、それこそ本来一緒に隣の席で仕事をすることが少ないはずのゴリゴリのインフラのキャリアをもったエンジニアもいて、話しているだけでも勉強になることが多いです。これは私はすごくいい環境かなと思っています。

裏方でも抵抗がない方におすすめ

どんな人におすすめかを書いてみたんですけど、1つここは考慮しておいたほうがいいなというのはこれですね。「裏方でも抵抗ない」。やっぱり裏方ではありますので、直接的にプロダクトを作ってユーザーに使ってもらいたい、そういうところにこだわりのあるエンジニアは、ちょっとSREは違うんじゃないかなと思います。

あとは、今はやっぱりリモートで作業しているというのもあって、「物怖じしない」というのも重要です。やりたいことは「やりたい」、やりたくないことは「やりたくない」、困ったときは「困った」、助けてほしいときは「助けてくれ」と、大声で叫べる人のほうが、仕事がしやすいんじゃないかなと思っています。

また、正直な話ですが、チーム内はけっこう年齢層が高いです。今全部で8人いて、そのうちの1人は最近合流した20代の若いエンジニアですが、その人を含めても平均年齢が約40歳ということになっています。正直に話しましたけど、別に誰も年齢は気にしていないので、皆さんも気にしないで応募してくださいということです。

あとはたまに、急な状況の変化で、私たちのチームでリソースがすごく足りなくなることがあります。実は今がそうなんですが、そうなった場合は開発チームのエンジニアに「助けてください」と一時的なヘルプを要請できます。

ただし、長期的にそういう状況が続きそうなときは、採用とか外部の会社さんにお手伝いしてもらうことを当然検討していきますが、「じゃあ来週から来てください」とはどうしてもいかないので、そういった方々がJOINしてくれるまでの間の時間を自分たちでしのがないといけない、ちょっとキツいタイミングが正直あります。

（スライド参照）私はだいたい1日こんな感じで働いていて、ちょっとお伝えしたいのは、私の家族は夕方6時ぐらいに帰ってきて9時ぐらいに寝ちゃうんですね。なので、ここの時間を家族と過ごさないと会える時間がなくなってしまうので、この時間帯はあまり仕事をしていません。

その代わり夜に少し追加でやるというような自由な働き方が可能です。

私の発表は以上になります。

LINE Fintechサービスのフロントエンドエンジニア

劉碩氏（以下、劉）：変わってここからは、フロントエンドのチームはどんな仕事をしているのか、どう仕事をしているのかを簡単に説明します。私は劉と申します。フィナンシャル開発センターのフロントエンドを担当しています。

フロントエンドと言ったら……フロントエンドですよね。私たちはユーザーが使っているUIの部分を開発しています。もちろん私たちだけでは開発できないので、企画のメンバーとサーバーサイドエンジニアのメンバー、デザイナーと協力しています。Web技術を使い、UIを開発するのが、私たちの役割です。

ここからは各部署とどのように関わっているのかを説明していきます。まずは企画からです。企画からは仕様書をもらうのですが、いきなり仕様書を渡されて「これを開発して」ではなくて、最初の段階から私たちもレビュー会に参加して、「これは実装しやすい」とか「この実装は難しい」とか、積極的に提案しています。レビュー会以外でも随時相談しています。最近はコロナのせいで、Slackだけでコミュニケーションすることが多いのですが、コロナ前は、席まで行ったり来たりしていました。

（スライド参照）これは、企画からもらうワイヤーフレームの一例なのですが、金融サービスなので、これよりもっと複雑なワイヤーフレームになります。

デザイン通りに実装する'Pixel' Perfect

仕様が決まったらデザインの段階に入ります。企画と同じようにレビュー会があり、私たちも参加しています。そちらに「このデザインが難しい」とか「こうしたほうがいい」とか、同じように積極的に提案してもらいます。もちろん無理はしません。実際に今誇りをもって実装しているのはページスタックというScraperで、ページトランジションの仕組みも私たちエンジニアから提案したものです。

LINEのウォレットタブにLINE証券のアイコンがありますので、もし興味があればぜひ触ってもらえるとうれしいです。

デザイナーのチームには韓国語のメンバーが多いので、コミュニケーションをするのはSlackで、通訳botを通じて話しています。

デザイナーからもらうのは、スタティックなデザインガイドとインタラクションなデザインガイドで、スタティックなデザインガイドのほうはZeplinで上がってきます。そちらにCSSのコードも入っているので、すごく助かっています。

デザイナーからデザインガイドをもらったらそれで終わるのではなくて、デザインQAと呼ばれる、実際に私たちがデザイン通りに実装しているかをデザイナーがちゃんとチェックしてくれるようになっています。

私たちはその作業を'Pixel' Perfectと呼んでいます。要するに完璧に実装しないといけないということです。私たちのチームはまだ若いので、最初の段階ではこの'Pixel' Perfectに対応するのに、すごく苦労したことがあります。

デザイナーの基準がわからなかったため、ワークショップを通じてデザイナーとお互いに話し合いました。やっぱり開発側としてはデザインシステムが望ましいのですが、デザイナーのほうは余白が大事で、全体的なバランスが大事ということがわかりました。

その後、余白と全体的なバランスのところ、とくに縦のアライメントについては心を込めて作りました。今は'Pixel' Perfectについてはスムーズに行なえている状況です。

開発からリリースまで

デザインが終わって実際の開発に入ると、PMの方がちゃんとスケジュールを立てて進捗管理もちゃんとやってくれるので、おかげで私たちが開発に集中できる環境になっていると思います。

サーバーサイドのエンジニアとのやり取りはほとんどAPIのスペックです。LINE証券はSPAなので、APIスペックについては事前に相談して、そのあとフロントエンドとサーバーサイドが同時に開発します。最後にAPI、エンジニアクエスチョンを確認して、QAに渡すという感じです。

フロントエンドは自分のAPIモックをもっています。Node.jsももっているので、ほとんどありませんが、一部のAPIはBFFを適用しています。

その中の一部で、サードパーティのライブラリも使っています。それを使う場合には、とくにコミュニケーション面で、たまに大変になります。

フロントエンドのチームが直接使っているLINE全体的な基盤のもの、NPMレジストリとか、CDNとか、CIを使っているので、そちらに問題がある場合は、直接インフラチームに話しています。Node.jsサーバーについては、正直なところフロントエンドのチームはそこまで精通していないので、SREチームにお願いしています。

（スライド参照）こちらがLINEのプライベートNPMレジストリで、フロントエンドエンジニアとしておもしろいものがあったら、全社的にシェアしましょうと心掛けています。

（スライド参照）これがフロントエンドのビルドのパイプラインですね。LINE証券内の1つのプロジェクトなのですが、フロントエンドにおいて下にもいくつかのサブプロジェクトがあって、そこのビルドがけっこう長い。今のビルドが1回10分ぐらいかかります。

あとたまにマーケティングチームからリクエストがきます。ほとんどはデータトラッキングまわりの挙動を計測してほしいとか、ここのログを取りたいとか、実装が不要なものなのですが、たまに実装しないといけないソースコードがあって、そこは大変です。

実装が終わったら、QAに入ります。バグやIssueの大半はフロントエンドのですが、幸い今年の4月からかな？　Android 4は切ったので、だいぶ楽になりました。

リリースしたらユーザーに触ってもらいます。私たちフロントエンドエンジニアとしては、パフォーマンスよりもスムーズさを求めています。JavaScriptでエラーが出た場合は、Sentryを使って収集しています。

「TypeScriptの神様」もいるチーム

今のチームの構成としては12名ぐらいいまして、大崎と福岡の2拠点あります。Slackで話すのは基本的には英語ですね。もちろんそちらに通訳botがありまして、英語と日本語のどちらでも大丈夫です。口頭では日本語ですね。

技術スタックについては、基本的にはTypeScriptとReactを中心にしています。それ以外にもいろいろ使っています。とくに「これを使っちゃだめ」とか「これを使わないとだめ」というルールはなくて、基本的に新しいものがあって使いたい場合は、提案して、チームで集まってディスカッションをして、その場で使う・使わないを決めたら、問題なければそのまま採用します。

もし結論が出なかったら、とりあえず一部のリスクの少ない部分に入れてみて、その結果を見ながら、チーム全体に浸透させるとか、がんばっています。例えば、今新しいステートライブラリにRecoilが出たのですが、それも実際一部入れてあります。

TypeScriptについては、ここが実際のコードのスクショなのですが（スライド参照）、そこまで完璧に求めることはなくて、ただたまにタイプまわりが難しいところがあります。うちのチームには、「TypeScriptの神様」と呼ばれている@uhyo_という方がいるので、もしTypeScriptに興味がある方なら、うちのチームはすごくいいところかなと思います。

フロントエンドといっても、テストはちゃんと書いています。とくにUnitテストは書いていますが、E2Eテストもがんばって入れてあります。E2Eテストを書くのはすごい時間がかかるので肝心なところだけ、重要ページの遷移とかのポップアップまわりだけ入れています。Droneを使っています。

コードレビューは活発にしています。プロジェクトが大きいため、他のメンバーが実際に何をやっているのかはっきり理解するのがすごく難しいので、できるだけコードレビューを通じてお互いに交流して定評につないでいます。これが実際のコードレビューのスクショですね。

私たちフロントエンドは、UXやパフォーマンスに妥協しない

「LINEの開発スタイルは？」とよく聞かれますけど、フロントエンドのチームは、独自の開発スタイルをどうするのか、今考えているところです。まだ終わっていませんが、例えば最近多いのが「シンプルなコードを書きましょう」「削除しやすいコードを書きましょう」ということでしょうか。

フロントエンドは、開発したものがけっこう変わりやすいので、新しいものが出たら古いものを消さないといけないですよね。だから最近は、「できるだけグローバルにしないでローカルにしましょう」という話をして、削除しやすいコードを求めています。

もちろん、フロントエンドもいくつかの課題を抱えています。さっき言ったとおり、大崎と福岡の2拠点あります。複数の地域で同じプロジェクトを開発すると、スタイルが違ったりデプロイプロセスが混ざったりして混乱を招くので、そこをどう解決していくのかが課題です。マイクロフロントエンドをいつか入れようと今考えています。

あとはSSRですね。SPAを使って開発しているのですが、これからブラウザでもLINE証券を開けるようになる（2020年8月26日より）ので、そこのSEOなどいろいろ懸念点があります。ですが、私たちががんばって作っているUXは、Nuxt.jsだけだとたぶんもう消さないといけないので、そこをどううまく共存させるかが、これからの課題です。

あとは複数のプロジェクトが同時に走ると、そちらの標準化はどうするのかも課題の1つですね。もしそういうチャレンジに興味がある方は、応募してみてください。

まとめると、私たちフロントエンドとしては、UXやパフォーマンスに妥協しない。たまには妥協するかも（笑）。いや、妥協しない！　新しい技術は話して積極的に入れられるような体制というのがワークポイントかなと思います。

UIT Meetup、LINE Engineering Blogなどさまざまなコミュニケーション

LINE全体的ではフロントエンドのチームがたくさんあって、東京、京都、韓国、ベトナム、台湾など、いろいろなところにあります。毎年、みんな同じところに集まってコミュニケーションをするのが、グローバルワークショップです。

去年は韓国で行って、すごく楽しかったです。今年はコロナのため開催されませんでしたが、来年はたぶんあるかなと思います。それ以外には、東京で定期的にUIT Meetupを開催しているので、もし興味があったらぜひ参加してみてください。

LINE証券のフロントエンドが、いろいろなノウハウをLINE Engineering Blogを通じて発信しているので、ぜひ見てもらえるとうれしいです。自分の発表は以上になります。ご清聴ありがとうございました。