自分たちが想定したものはけっこう簡単に崩れてしまう
司会者：ありがとうございます。チャットを送ってくださったみなさんありがとうございます。ではさっそく、パネルトークに入っていきたいと思います。いくつかテーマを用意しているので、そちらをピックアップしながら話してもらおうと思っています。
今回、4つピックアップしているのですが、チャットで「これってどうなっているんですか？」みたいなものがあれば、適宜拾っていこうと思っています。チャットやQ&Aを送ってもらえるとうれしいです。
最初のテーマは「急成長の中で起きた技術課題」です。2020年はコロナの影響もあって、noteもBASEも大きな変化があった年かなと思います。
技術課題についてぜひおうかがいできればと思います。まず川口さんからBASEの技術課題についてお話いただけますか？
川口将貴氏（以下、川口）：コロナ禍でECの需要が高まりショップ開設数が急増しました。なので、これによる負荷問題が一番大きかったと思っています。特に2020年の4月、5月あたりは大変なご迷惑をおかけしてしまったというのがあります。
3年や5年先に考えていたアクセスの量が実際発生していました。ブログでも2020年8月くらいに書いたんですが、エンジニアは、ある程度まではAWSのインフラなどにお金をかければなんとかなるだろうと思ってはいました。実際、増強もしたんですが、それを超えた課題でした。
きちんとアプリケーションの部分などを見直さなきゃいけないとか、接続の管理をどうするのとか、コネクションプーリングをきちんとやるとか、2020年にコネクションプーリングのこと考えるのかって若干思ったりもしました。
漸近的にアーキテクチャなどが進化していくので、大丈夫だろうと想定していたものが、唐突に来るというのがほぼ初めての経験だったので、そこらへんはいまだに課題としては残ってはいます。世の中がどう変わっていくかもわからないし。
BASEはコロナ禍以前、リモートは基本的にはしない方針でやっていました。それがコロナ禍の今は社員の8〜9割くらいがリモートを選択している状態です。そんな状態で大きな障害が起きているので、自分たちが想定しているものって、けっこう容易に崩れるということが、2020年は起きたなぁと思っています。
サービス的には需要が高まり利用は増加しているんですが、自分たちがそれに見合った成長ができているかというと、まだまだやらなきゃいけないことがすごくあって、苦しいですね。苦しいというか、やることや課題がたくさんあります。
アプリケーションの負荷などは対応することがまだすごくあります。でも開発のプロセスを止めたくもないし、どう優先順位づけていくかはけっこう課題ですよね。
限られたエンジニアメンバーではあるし、採用も強化するとはいえ、人が増えたら負荷対応と開発が両立できるかというと、それはまた別の話なので。どこを取捨選択していくかはけっこう難しいなぁと思っています。noteさんはどうですか？
CTOになって一番しんどかった障害対応
今雄一氏（以下、今）：noteでもほとんど同じ問題が2020年に起きました。ユーザー数がDAUで言うと3倍くらいに増えました。BASEさんとまったく同じで、2020年4月、5月の緊急事態宣言あたりですね。みなさん巣ごもりになって、インターネット全体のトラフィックが増えたのか、noteで記事を書いたり、買ったりというアクションがけっこう増えて、データベースのWriteもReadも増えました。今のインフラのスタックで1、2年は保つでしょと思っていたんですが（笑）。
川口：そう、保つでしょって思うんですよね。でも保たないっていう。
今：そういう感じでキャパプラ（キャパシティプランニング）をしたり、データベースインスタンスの計画を立てたりしました。コロナは来ているけど、なんとかなるんちゃう？ と思っていたんですが、ぜんぜんならず。緊急でスケールアップをしたり、本番でISUCON（決められたレギュレーションの中で限界まで高速化を図るチューニングコンテスト）をやったような感じでした。
川口：リアルISUCONでしたねぇ。
今：リアルISUCONをやりますという感じで、みんなでスロークエリ見て、「はい、潰します」みたいな感じでした（笑）。けっこう痺れる感じでしたね。やっぱり書き手が増えました。
川口：へ～。
今：BASEでもショップ開設がたくさん増えたと思うんですが、どうですか？。
川口：そうですね。ショップ開設がたくさん増えたっていうのはありますね。
今：ECでもテキストメディアでも一緒ですが、インターネットでの発信ですね。それが求められている時代のフェーズになったんだなぁとひしひしと感じました。
川口：うちは、DBのコネクション数はぜんぜん平気だけど、唐突につながらなくなったり、DBへの接続が10secくらいかかったりするようになりました。
今：最初のコネクションですか？
川口：はい。AWSのエンタープライズサポートに入っているので、調査しました。それこそEC2に入って、そのときのtcpdumpを見ました（笑）。
今：はいはい（笑）。
川口：2020年にtcpdumpなんてとっているのか？ とちょっと思いつつも（笑）。実際、遅くなっているのを見たんですが、結局最初のときは、バックログのパラメータが足りていなかったんです。うちはAuroraを使っているんですが、クラウドECが載っかりすぎると、Auroraでもこういうパラメータをきちんといじらないといけないんだなって思いました。
今：Auroraでデフォルトのパラメータをいじるっていうのは、なかなか強烈に使っているんだなぁっていう感じがしますね。
川口：そこまで触らないといけなくなったなという気持ちはあります。
今：ただAuroraって、CPUが100％に貼りついても、けっこう粘るじゃないですか。
川口：粘りますね。CPUのアラートは、そんなにセンシティブに気をつけるものではないですが、実際はつながらなくなるサーバーがありました。最初は本当にぜんぜん原因がわからなくて。
今：そうですよねぇ。障害対応って、基本的にはまず現象を確認して、メトリクスを見て、方法を考える。知っているパターンだったら対応して、知らなかったら調査からって感じだと思うんですが、だいたい調査から始まるパターンも多いですよね。
川口：そうですよね。本当にISUCONなんですよね。
今：そうなんですよ。しかも本気勝負のISUCON。
川口：コンテストじゃない（笑）。
今：直さなあかんやつなので（笑）。
川口：直さなあかんし、スコアも出ない（笑）。
今：マイナスがゼロになるだけなので（笑）。
川口：うちのときは、だいたいピーク帯が19時、20時、21時と、ショップさんが商品を売り出す時間帯に問題が起きるのが多かったです。1日対策を入れて、翌日の19時まで待つ感じでした。
今：それもめっちゃわかります。毎日答え合わせしているような感じ。
川口：そう、毎日答え合わせをして、だいたい失敗しているっていうやつ。あのときがCTOになって一番しんどかった気はしますね。
今：そうですね。僕もけっこう張り付いていましたね。
川口：眠れなかったです（笑）。原因がわからないと、いつ起きるかもわからないので。時間帯では、アクセスが多いとなるんだろうなとは思いつつ、12時だったら大丈夫とか、2時だったら大丈夫という保証もないので。
今：ないですよね。
川口：最初の緊急事態宣言下で、さすがに外に出ることはなくて、悩む時間がいくらでもあるので、精神はちょっと摩耗しましたね。
障害対応って大変なんですが、オフラインだったらちょっと話しながらとか冗談言いながらできます。でもそのときは完全リモートだったので、「Zoom」でつないでやっていても……メンタルにはすごくきましたね。
今：Zoomを使うのがけっこうコツですよね。
川口：とりあえず集まる。
今：とりあえず集まるのって、本当に大事だなと思います。
川口：当分あれは考えたくないですけどね（笑）。ただ課題がいっぱい見えたので、それはよかったです。
今：僕も結果的には、負債を早めに返却できたと前向きに捉えています。
BASEとnoteの共通課題 経理のレガシー
司会者：ありがとうございます。BASEの社内で見ていても、2020年4月は大変だったなぁと思っていました。
例えば当時は、AWSのインスタンスを増やすだけでは解決しないという課題もあったかと思うんですが、これはちょっと取り組まないといけないなという具体的な技術的な課題はありますか？
川口：サービスが急増してアクセスが増えて、そのアクセス自体の安定性は課題として検知していて、これからもやっていくんですが、例えば、ショップさんの売上金は、いったんBASEが預かっていて、経理が振り込みをするんですが、ショップさんが新しく増えたときに、経理の業務が逼迫するという課題はあります。
銀行に振り込む部分って、めっちゃレガシーなんですよね。どんどん線形に増えていっても、ぜんぜん楽にならない。
エンジニアのテクノロジーでそこの業務フローを解決できないかなと、うちだとCorporate Engineeringのチームを立てて解決しようとしていますね。まだまだ課題は多くて大変ですが。
ほかにも不正決済も当然増えていくので、そこらへんの対策は考えていますね。
今：うちは、負荷はわりとテクニカルな話なので、粛々と問題を発見して潰すだけなんですが、トラフィックやトランザクションが増えると、それに比例する以上にトラブルや想定外の事態も増える印象があります。ユーザーが3倍になって問題が3倍になるかというと、5、6倍になる感じがあります。
うちもBASEさんとけっこう似ていて、CtoCのプラットフォームなのでお支払いの仕事もあります。やっぱりイレギュラーなケースも増えて、経理と「これどうするんだろうね？」と話しています（笑）。
川口：想定していない部分が出てきますからね。こんなことあるの!? っていう。
今：そうなんです。詳しくは言えないんですが、「なるほど！」というものもあります。当社に限らず、不正決済もすごく増えているので、当社もそこを問題視して、検知する仕組みをルールベースで作りました。
やらないといけないことが急に増えて、しかも予測不可能という感じでしたね。守り系の専門チームを作って、順次対応しているんですが、さらにまたやることは増えそうなので、強化して取り組みたいです。
川口：こういう課題ってすごく地味だから、簡単でしょって思われがちなんですが、実際はすごくテクニカルな要素が必要です。課題者をヒアリングしないと、ルーチン系の業務って本当は遠回りなことをしているのに、みんな慣れちゃってけっこうそのままやっているところもあるので。
そこらへんの課題をきちんとヒアリングして解きほぐして、最後に技術で解決するみたいなところがあるので。エンジニアリングとしてもすごく大変な業務だと思うんですよね。
今：でも間違いなく尊くて、大事な仕事ですよね。
川口：本当にそうなんですよね。コーポレートエンジニアやCREはすごく難しいわりに過小評価されがちなので、もっときちんとスポットライトを当てていかないと、と思います。
それこそ全銀（全国銀行データ通信システム）のデータなどもあって、そもそも経理系の業務自体がすごく大変なので（笑）。銀行コードに詳しいだけで、だいぶ強いです。
noteはマイクロフロントエンドでアプローチを変えている
司会者：オペレーション面や組織面の課題も予想外に出てきたという感じなんですね。技術的な課題もいくつか起きているのかなと思うんですが、その中で今取り組んでいるものはありますか？
川口：コードベースが大きくなってきていて、負荷対応で即座にコードをデプロイして課題を解決できるか確かめたいっていうときに、デプロイがけっこう遅いのが課題です。
打席に立つ回数がどうしても減って、リリースに対する不安が増えるので、デプロイフローの改善のスキルアップは喫緊の課題ですね。
今：そうですよね。サーバー台数に比例して増えがちというか。
川口：それこそ、昔は、JavaScriptをビルドするなんてなくて、JSは書いてあるからいいでしょって（笑）。PHPやソースコードをいかにプル型にするかプッシュ型にするかという話で盛り上がっていたと思うんですが、今はJavaScriptのビルド部分がすごく時間がかかる。
今：あ～はいはい。
川口：そこの時間がすごく増えていて、スケールしないというのは、実際うちでもあって、課題です。JavaScriptのビルドをやめるのもぜんぜん想像できないですし。
今：フロントエンドはうちもけっこう肥大化しています。もはやメモリ32GBのMacでは足りない感じになっていて。
川口：あ～わかります。
今：1日に何回も落ちるんですよね。
川口：そうですね、マシンも問題というよりは、こんなにかかるようになったんだ。富豪だなぁと思って（笑）。
今：Nuxt.jsに移行した最初の頃は、「お、軽くなった！」「イノベーションが起きた！」と喜んだのですが、時間が経つとまたすごく肥大化して。
川口：エンジニアに貸与するマシンも、ネイティブエンジニアはいいスペックが必要だ、iMacのProだとか言っていて。普通のバックエンドエンジニアはそんなに使わないしと言っていた時代があったのに、今はローカルにDockerとChromeとwebpackがあるだけで32ギガ必要ですみたいな感じ。
今：そうなんですよ。今の環境って32ギガがスタートラインなんですよね。
川口：そこに投資するのは当然なのでいいんですが、「そんなに必要なんだ!?」って思う部分は確かにあります。
今：そうですね。ひと昔前の世代としては。
川口：M1 Macは動けばめっちゃいいですよ。動けば（笑）。
今：確かに。もうM1 Macは投入しているんですか？
川口：いや、うちでは僕が使っているだけです。開発環境として動くかどうかが微妙で、Dockerもまだプレビューなので。入社した人にいきなり開発できませんとか、ローカルでがんばってねとか言うのもあれなので、いったんIntel Macを貸与しています。
実際僕が使って、ほかのコミュニティにイシューを立てているんですが、ローカルの開発環境がどうしても動かないので。早く直してくれ～って感じですが。それ以外はメチャクチャいいですね。Zoomをしてもぜんぜん電池減らないし。
今：いいですね。楽しみですね。ちょっと精査待ちですけど（笑）。
川口：エンジニア以外だったらコスパがいいなって思います。
今：一部の社員には配られていて、指を咥えて見ています。
川口：すごく便利なので、おすすめです。実際検証はしているけど、まだ動いていないので検証はできていない（笑）。
今：要は検証失敗ですね（笑）。
川口：検証失敗しています（笑）。
今：フロントエンドは、最近ちょっとアプローチを変えています。サブドメインごとにフロントエンドと分割しようかなと思っていて、詳しくは言えないんですが、メインはNuxtで、新しく作っている機能やリニューアルしている機能はもはやリポジトリも別だったり、そもそもReactアプリだったりします。そういった感じでドメインを分割していく方向にフロントはしようとしていますね。
川口：なるほど。マイクロフロントエンドってやつですか。
今：そうですね。最近よく聞く（笑）。
川口：最近よく聞くやつですね。BASEも全部マイクロサービスにするかっていうのはなかなか……、そもそもコンテキストの分解点がすごく難しくて、一大作業になるので、僕はマイクロサービス苦手な人間としてですね（笑）。やってはいるんですけど。
とはいえ1個のサービスで全部やっていくのはもうそろそろきついので、適宜分割はしていかんとなぁとは思っています。
今：基本的にはどこかで天井が来るというか、運命は見えているので（笑）。いつ手を打つのかっていうことですよね。
（次回へつづく）
