メルペイの信頼性はいかにして作られているか
高木潤一郎氏：それでは「メルペイの信頼性へのチャレンジ」というタイトルで発表します。私は高木潤一郎という名前で、Twitterは@tjunというIDでやっています。
SREとしてメルペイに入社して、最近はエンジニアリングマネージャーもやっています。
今日は信頼性の話をしようかなと思っていまして、アジェンダを考えるにあたってなにかいい話をしてくれと言われたので、信頼性というテーマでお話しようと思います。
まず、今日のテーマ「信頼性とは何か」を考えてみました。
メルペイはご存じのとおり金融サービスですので、信頼性がとても大事です。例えばお店で決済しようとしたときに使えないとか、その決済が10秒かかるといった体験が続くと、使ってもらえないサービスになってしまいます。
なので、いつでも使えて当たり前ですし、そうやって買い物したときに残高が合っていないと、それも使ってもらえないので、常にちゃんと正しく動く、そういう高い信頼性がメルペイに求められています。
ですので、今日のテーマであるBold Challengeを考えたときに、目指すところは信頼性100パーセントなのかと考えるわけです。ですが、それって実は正しいゴールではないかなと考えています。
正しいゴールとは何かと考えたとき、信頼性をつくるには時間とお金がかかります。今動いているメルペイにさわらなければ信頼性が高い状態を維持できるかもしれませんが、今後我々は信頼性以外の価値を提供していかなければならないので、そういったところで機能を追加したり、サービス追加したり、そういった変化やチャレンジをやっていかなければならないと考えています。
一方で、「信頼性上げましょう、Reliability上げましょう」というと、いろいろなリリースのプロセスを厳しくしたり、テストをいっぱい書くようにしたり、いろいろな検証を増やしたり、そういったことをガチガチにすれば信頼性を上げることは可能です。
ただ、そういうことをガチガチにしていくと、開発速度がどんどん落ちてしまいます。信頼性を高めるという目標も大事なんですが、そのバランスをどう見ていくかが非常に大事かなと思っています。
高い信頼性を実現するための3つのステップ
こうやって高い信頼性を考えるにあたってどんなステップがあるか考えてみると、ここに書いてあるような3つのステップに分かれるのかなと思います。
最初に、目指す信頼性についてです。どんな信頼性をターゲットにして、なにを目指していくのか、ゴールを決める。次に、そのゴールが達成できているのか・できていないのかをちゃんと見る。最後に、一度達成したゴールを常に達成し続けるような仕組みを作って、新機能を追加してもその信頼性を維持する。そういった3ステップがあると考えています。
この最初のステップにおいて、まずは目指す信頼性を定義するところで使っている仕組みとして「SLO（Service Level Objective）」というものがあります。これはSREの本にも出てくる考え方です。SLOとは何かというと、サービスが実現すべき数値の目標みたいなものです。
例えば我々のサービスで決めるとしたら、例えばiD決済のリクエストが99.99パーセントは成功しますよという目標になります。まれになんらかの理由で失敗してしまうけど、 失敗率が0.01パーセント以内なら許容する。そういった目標を決める。
こうやって目標を決めることの何がいいかというと、例えばSLOを99.99パーセントとするとしましょう。そうなったときに、我々は信頼性を実現できているのか、あるいはできていないのか。目的としているお客様の体験を実現できているのか、あるいは実現できていないのか。そういった判断が可能になります。
なので、もし目的とするSLOを達成できていないのであれば、新機能の開発を止めてでも今のサービスの改善をすべきですし、逆に今達成しているのであれば、改善はそこまでしなくても、新しいチャレンジがまたできるよねと。そういったチャレンジや改善の基準となるような目標。それがSLOなのかなと思います。
なので最初に話したように、単純に高い目標を設定すればいいというわけではありません。適切な目標を決めることで、次にチャレンジをするためのエンジニアリングのリソースですとか、チャンスをつくる基準なのかなと思っています。
そうした信頼性を誰が実現するのかということを考えたとき、僕のチームであるSREはもちろんその役割を持ってはいますが、とはいえ、SREが実際のアプリケーションのコードを書くわけではないですし、そのバグを直せるわけでもありません。私たちはあくまで基準を作ったり仕組みを作ったりするサポートはしますが、SREだけでは信頼性を実現できません。
では、すべてのエンジニアが信頼性を考えればいいのかというと、実はそうでもなくて。先ほど言ったように、信頼性はバランスですので、組織として、我々はどこで信頼性を目指すのかを決める必要があります。
先ほど紹介したSLOも、単純にエンジニアだけが決めているわけではなくて、メルペイではPMとテックリードが話し合って決めています。PMとしてはお客様の体験を上げたいのでこういう値を目指したいけど、技術的にはこれだと難しいとか、そういったいろいろな制約があるなかで決めていくものですので、そういう意味でもエンジニアだけで信頼性をつくるわけではなく、組織として合意して決めていくものかなと考えています。
メルペイに入社してやったこと
ここまでは、信頼性をどうやって我々が考えてきたかというところを紹介しました。次は、メルペイをリリースするにあたってどんなことをやってきたかを紹介したいと思います。
まず簡単に、自分が入社してから、あるいはSREチームとしてどんなことをやってきたかを紹介します。僕が入社したのは2018年の4月です。メルペイには、最初のSREとして入りました。
最初、SRE1人だし、とくにできることもないので、入社1ヶ月ぐらいでいきなりメルカリのマイクロサービスプラットフォームチームに混じってプラットフォームを良くしていく仕事をしていました。
プラットフォームとしてメルペイに必要な機能を入れたりといったことに取り組み、夏ぐらいから、メルペイのリリースに向けて信頼性をどう考えていくか、そんなことを考え始めました。
例えば、必要なインフラを作ったりリリースや運用のルールや仕組みを作ったり、リリースに向けて何が必要か、そんなことを考えていました。その頃はSREも僕だけでなく人も増えて少しずついろんなことをやれるようになって、リリースに向けた準備を進めてきました。
そんな感じでやってましたが、自分がメルペイに入社してリリースを考えるにあたって、いろいろ難しいなと思った点があります。
メルペイに入る前は自分は新規事業など小さなサービスのリリースを経験してきました。最初は使う人がそんなにいないので、まずは出してみて出しながらちょっとずつ改善していけばいいかなというサービスが多かったんですが、メルペイの場合は、いきなりメルカリアプリにメルペイ用のタブができるので、リリース直後から、かなりの数のリクエストが来ます。
しかも金融サービスなので「出してみたらうまく動きませんでした。ごめんなさい」が許されない部分もあります。それに加えて、メルカリとつないでいく、あるいはメルカリからの機能移行もあるという複雑性があって、かなりリリースを難しく考えていました。
そのほかにも技術的なチャレンジがありました。先ほどdeeeetさんの発表にもあったように、マイクロサービスアーキテクチャの上で金融サービスを作らなければいけません。マイクロサービスアーキテクチャにすることでが良い点もいろいろありますが、逆にマイクロサービスならではの難しいところも結構あったかなと思っています。
ここに書いてあるようにいろいろ考えることがあって、それぞれメルカリのテックブログなどで紹介してはいるんですが、今日のテーマであるマイクロサービスの信頼性、そこをSREとしてどう考えていくのか、去年の夏頃から考えて動いていました。
マイクロサービスの信頼性を高めるためにやったこと
SREがやってきたこと、あるいはSREに近いチームとかそういうチームを巻き込んでやってきたこととして、大きく分けてこの3つがあるかなと思っています。
1つは共通のインフラの構築です。マイクロサービスといってもいろんなサービスがありますが、とはいえインフラとして共通部分もあるので、そこをちゃんと整えて決済の基盤として耐えられるものにしていく。まずそういうことをやっていました。
次に、最初に紹介したSLOのほかにも、リリースのためのフローを整備したり、あるいは障害が起きたあとの対応フローを整理したり。あとはリリースに向けていろんな設定をレビューしたりなど、マイクロサービスの開発運用のサポートもやってきました。
SREだけでなくアーキテクトチームと一緒にやってますし、SLOを組織全体に落とすときにはVPoEのhidekさんの力を借りたり、いろいろなチームの協力を求めながら、信頼性をどうやって作っていくか、リリースに向けて考えてきました。
去年の年末から1月にかけていろいろな大変なことがあったんですが、なんとか2月に無事にリリースができたので、めでたしめでたしという感じです。
障害は起きる前提で考える
今までの話は、なんとかリリースできていい話っぽい感じなんですが、とはいえ、そんなに世の中甘くありません。リリースしてみたらやっぱり問題はいろいろ起きました。
メルペイのサービス運用、理想的にはクラウドを使ってフルマネージドなデータストアを使っていますし、Kubernetesは全部オートスケールしてオートヒーリングするので放っておいても運用しなくてもよねと。エンジニアも優秀ですし、テストやQAもかなりちゃんとやっているので、そんなに問題は起きないでしょうと思うかもしれません。
あとは、メルペイはいろいろなパートナーサービスと連携していますが、我々よりもちゃんとした会社が提供している実績あるシステムなので、「まぁ大丈夫でしょう」という感じで最初は考えていました。
でも、実際運用してみるとそんなことはなく、クラウドにももちろん大小いろんな問題が常に起きますし、インフラの問題で自分たちにどうしようもできないこともあるし、あるいは設定をミスっていることもあるし、なにかツールのバグを踏んでいるということもあります。
また、自分たちのコードが期待どおりに動いていないこともあれば、使っているライブラリで予期せぬ問題が起きていることもあります。パートナーのサービスももちろん障害が起きることもあります。
もちろんあらかじめわかっていたことでして、ちゃんと準備しても障害は起きるよねと。そんな前提で開発や運用の仕組みを整えていくことも大事かなと思っています。
大きく分けて、2つやっていることがあります。1つはObservabilityです。ちゃんと自分たちのシステムやサービスがどんな状態なのかを見えるようにして、なにか大きな問題があったら気づけるようにする。
あとはインシデントが起きたときにも、どうやって早く気づいてそれを対応するか。それはもちろんエンジニアがバグを直すだけではなく、お客様にコミュニケーションすることもあれば、パートナーとのコミュニケーションもある。そういったいろいろなフローが必要です。
そういったところをあらかじめ準備しつつ、今も改善をしながら信頼性について考えています。
今話したとおり、信頼性はサービスをリリースしてOKというものではなく、リリースしてからがむしろスタートみたいなところです。サービスを運用して改善していくなかでだんだん高めていく、そんな感じのものかなと考えています。
信頼性を達成し続ける仕組みを作る
最後に今後のChallengeについて話します。今までメルペイのリリースまでどんなことをやってきたか駆け足で紹介して来ましたが、今後は我々がどんなチャレンジをしていくのか考えてみました。
最初の話に戻りまして、信頼性って結局何だったのかを考えてみると、信頼性とは、メルペイが提供する機能の中で、すべてのお客様が使う一番大事な機能かなと僕は考えています。なので、SREは裏方のように見えて、実は大事な機能をやっているチームでもあるなと思っています。
最初に3つステップを紹介しました。
SLOで信頼性を定義するという部分はすでにできていて、2つ目の実現できているかどうかを確認するというところもメトリクスを取れるようなダッシュボードを用意して、一応確認できるようになっています。ただ、今後信頼性を達成し続けて、さらにより高い信頼性をつくり続けるためにはどうすればいいか？というところがまだできていないところです。
最初の絵に戻って、VelocityとReliabilityの図がありました。Reliabilityを今後も高めていくには、開発速度をより遅くしてReliabilityに時間を割けばいいという考え方ももしかしたらあるかもしれませんが、メルペイは今後もいろいろな機能をどんどん出し続けて、どんどんチャレンジして新たなサービスを提供して、新たなお客様を獲得していくというフェーズにあるので、Reliabilityばかりやっているわけにはいかないというのがあります。
なので、欲張りなんですけれども、信頼性ももちろん高めたいんですが、新たなサービスや新たな価値もどんどん提供していきたい。
そういったなかで、我々の新しいチャレンジって何かなと考えると、SREもそうですが、いかにソフトウェアの力を使ってより少ないコストで高い信頼性を実現するか、そこがおもしろいチャレンジなんじゃないかなと思います。
共通基盤を整えるのも1つですし、例えばサービスメッシュなどの技術を試して、そこでより安定した基盤を作る、それがもしかしたらより高い信頼性につながるかもしれないですし、あるいは、各マイクロサービスのチームたちが今より少ない運用コストで運用を改善できるような仕組みを作ったり。そういったソフトウェアでの自動化を入れていくことで、より高い信頼性を少ないコストで実現できるんじゃないか考えています。
なので、我々のSREを中心としたNext Bold Challengeとしては、信頼性を達成し続ける仕組みを作って、その上でメルペイの新たなチャレンジを加速できればいいのかなと考えています。
発表は以上になります。ありがとうございました。
（会場拍手）
