バックエンドの概要
こんにちは、シニアソフトウェアエンジニアのriddleです。
こんにちは、ミドルソフトウェアエンジニアのひびのです。
このポッドキャストでは、僕たち2人でIT業界に関する様々なこと、技術、キャリア、その他諸々などなどなど話して、僕たちのリアルをお届けようという趣旨の番組です。
今日のテーマがですね、https://roadmap.sh//backendを読む、イエイ。
これはですね、バックエンドの開発者の人向けのロードマップをですね、海外の方がまとめてくれているサイトでして、一通りやればね、バックエンドエンジニアとしては一人前になるよという旅です。
もちろん全部やるのは大変なんですけど、こういう要素がありますよっていう紹介とですね、そこでこんなことを学べばいいんじゃないのみたいなところを、現役のバックエンドエンジニアである私たちがちょっとしゃべろうかなという感じです。
はい、私たち、つまみつまみしております、バックエンドを見ていきましょう。
ではですね、最初にインターネット。これね、フラントエンドの回でも話したんですけども、基本的にインターネットがどのように成り立っているかっていうのをざっくり知ればいいかなと思っています。
Httpとかドメイン名とか、どうやってホスティングしているのか、誰がホスティングしているのか、DNSとは何をしているのか、ブラウザはどう動いているのかなどですね。
大事ですね。
で、バックエンドなんですけど、フラントエンドのベーシックなことも分かってないといけないよねみたいなところで、実際にそんなに書ける必要はないと思うんですけども、画面を構成している要素として、HTMLとCSSとJavaScriptがあって、それぞれ何が何をしているのかっていうのを明らかにしておくっていうところが大事かなと。
そうですね。あとサーバーサイドエンジニア専門でも何というか、HTML、CSSで簡単な管理ツールとか作れると助けになることもありますね。メッシュの種の。
そうですね。で、このタイミングだとバックエンドの言語を1個選んでおきましょう。1個じゃなくてもいいんですけど、JS、Python、Java、PHP、Go、Ruby、C-Sharp、Rastonみたいな感じですね。
仕事として多いのはJavaとかRubyとか、PHP多いのかな。
まだまだあるイメージですね。
そうですね。ノードがどれくらいあるか分からないですけど、JavaScriptやっていたらフロントエンドもいけるかもみたいなのはありますね。
そうですね。
で、とりあえずここまででビギナーってことであるので、続いていくと、GitとGitHubを使えるようになりましょう。
そうですね。Git、この前僕らの回でも話しましたけど、簡単なコマンド以外は、簡単なコマンドくらいはソラでも使えるようになっておくと便利ですね。
リレーショナルデータベースの理解
はい。で、そこからが次、Relational Databaseですね。ここで来るんだ。
でもここからちょっとサーバー特化っぽくなりましたね、トピックが。
そうですね。Relational Databaseっていうのは、今ではもう本当にデファクトに近いデータベースで、データベース何かっていうとデータ保存する単純な場所ですと。
Relational Databaseは表形式のデータベースになっていて、行と列で表現されるようなものになってるんで、エクセルを思い浮かべていただくのが一番早いかなと思いますが、
まああんな感じのテーブルと呼ばれるところにデータをどんどん掻き溜めていくっていうのがバックエンドのあるあるなデータ保存方法ですね。
そうですね。この人のパーソナルリコメンデーションがポスグレなのちょっといいですね。
いや海外は割とポスグレが多いから、これなんじゃないかな。
本当ですか?そうなんだ。むしろ日本だとほとんど現場だとMySQLが多いような気がしますよね。
そう、日本はMySQLなんですよ。だからタイデイビーっていう中国が作ってるニューSQL、ちょっといきなりレベルが上がりすぎたんですけど、ニューSQLはMySQL互換なんですけど、
AWSが作ってるニューSQLのDSQLとかクラウドスパナ、Googleのクラウドスパナとかはポスグレ互換ですね。
そうだったんだ。知らなかった。意識したことがあった。僕、いやポスグレを通らずにスパナを最初に触ったので、いやそうだったのかと今、アハ体験となりました。
そうですね。ちょっと飛びすぎたんですけど、リレーションデータベースとしてはMySQLとかポスグレとかオラクルとかいくつかのものがありますね。
で、ここで一応マイグレーションっていう概念は覚えておかなきゃいけなくて、データベースはどういうテーブルにするかっていうのをスキーマっていうもので表現するんですけども、
例えばユーザーテーブルってものを作ったらユーザーIDとユーザー名とユーザーが作成された時刻とかみたいな、そんな感じで列、カラムを持つんですけど、
これを途中で変えたいなってなった時にそのマイグレーションという操作をします。
で、このマイグレーションというのは結構厄介だったりもするので、このまず概念として覚えておきましょうというのと、
自分が使っているデータベースに合わせてやり方を知っておきましょうみたいな感じですね。
大事ですね。
実際に運用しないとどれくらい大変かって分からないと思うんで、とりあえずここでは概念を押さえておくのでいいかなと思います。
そしてNプライチ問題。懐かしいな。
急に来るんだな、Nプライチここで。データベースにアクセスする際ってアプリケーションからSQLってやつを叩くんですけど、
例えばセレクトアスターフロムユーザーって書くとユーザーのテーブルから全部の情報を引っ張ってくるみたいな感じなんですけど、
そういうことは基本やんないんですよ。なぜならば重いんで処理が。ユーザーが1万人いたら1万件データ取ってくることになるんで。
なので基本的にはIDをベースにしてユーザーID1の人を持ってくるみたいな感じなんですけど、
例えば処理でユーザー100人分データを取りたいみたいな時に愚直に書くとフォールループで100回回してセレクトを発行するみたいなことをやりがちなんですけど、
これのことをNプラワン問題と言います。
これ何が問題かというと100回セレクト分叩くとクッソ重くなるので、1回例えば10ミリ秒で終わっても100回叩くと、何秒だ?
APIとセキュリティ
100秒?10秒かな。
10ミリ秒だから100回叩くと1秒ですね。
1秒ですね。1秒だからめっちゃ遅くなるんですよね。そういうのはやめましょうっていうことがここで紹介されてます。
そうですね。たぶんそれこそ新卒で現場に入って最初にベテランの人からレビューで指摘されるような内容ですね。
そう。だからセレクトの時にいっぱいIDいっぺんに渡して一発で取りましょうみたいな話です。
で、これが終わるとAPIについて学びましょうって話で、
こういうAPIはWeb系のAPIで我々がバックエンドサーバーとして作るWeb APIとかREST APIとか呼ばれるものの類が多いかなと思いますと。
大きく分けてRESTとGraphQLとGRPCぐらいよく使いますね。
JSON APIはもう最近はほとんど使わないけど、MCPって使うのかな。
JSON APIってあれですか。JSON RPCとかああいう類のやつですかね。
そうかな。
たぶんRESTと分けてるならそういうことなんでしょう。
REST分けて単純にJSONで送ってるって感じのやつですね。SOAPは昔のやつですね。
特にRESTをほとんどのケースで使うことが多くて、このRESTを管理するための共通のスキーマというかお約束ごとがOpen APIって呼ばれるもので、
基本的にはOpen APIのスキーマってものを定義して、こういうAPIをこのサーバーは喋りますよ。
なんでクライアントはそれに従って叩いてねみたいなことをクライアントサーバー間で合意を取るためのドキュメントというかスキーマファイルです。
そうですね。
で、プラスなんかめっちゃ色々あるけど、Authentication、だからAPI叩くための認証のところとか認可のところとかがあって、JOTとかAUTHとかレシク認証とか色々ありますよ。
なんで結構サーバー側だと自分でセキュリティをしっかり守るところの仕事の範疇だったりするので、今回のこの認証では何を使うべきなのかっていうのは、色んな認証の仕組みを知った上でどれが最適なのかとか、どれがビジネス的に求められているのかっていうのを判断して使いましょう。
そうですね。大事ですね。
で、Webセキュリティがあって、急にハッシュアルゴリズムの話が出てきたんですけど、これ何だろうな。多分おそらくユーザーパスワードみたいなものを必要なWebサービスが大半だと思うんですけども、その時のパスワードの保存方法とか、何かを生成してユーザーに返すみたいな時にハッシュアルゴリズムみたいなものを使うんですけれども、
その時にMD5とかSHA256とか使うんですね。RBクリプトとか。
ありますね。
なのでそういうものを最低限知っておきましょうぐらいの話だと思います。
大事です。
で、その下にさらにACPSとかOSPとかCORSとかSSLTとかCSPとかサーバーセキュリティとかのが丸っと書いてありますが、APIサーバーっていろんなところからアクセスされるので、セキュリティには気をつけましょう。
そのための方法として、通信路を暗号化するものであったり、そもそもおかしいリソースを返さないようにする仕組みだったり、そもそも変な人から叩かれないようにするとか、そういういろんな仕組みがあるので、そういったものも、ちょっとこのタイミングで本当に覚える必要があるのか怪しいんですけど。
ここで急に。
まだAPIサーバー作れてるのかな。作れてるぐらいのレベルだと思うんだけどな。
ここで急にヘビーになってきましたね。
ここでみんな脱落するんじゃないか。何にも面白くない。
何というか、でも全部触る必要はなくとも、たぶん一つAPIエンドポイントを作るために包括してさらりと知っておく必要がありそうですね。この辺りの知識は。
キャッシングとWebサーバーの役割
じゃあこの1個前の回にフロントエンド取ったんですけど、フロントエンドと違って楽しみというか苦しみとか多そうなロードマップだなこれ。
確かに。何というか脱落しそう。
無骨過ぎないか。
脱落しそうだな。
脱落するでしょこんなの。
次キャッシングですね。
キャッシング大事ですね。
データベースにデータを貯めるんですけど、データベースへのアクセスってちょっと遅いんですよね。
ちょっと遅いんでもっと早くしたいなっていうところで、データベースって基本的には物理のディスクに保存するんですけど、キャッシングっていうのはメモリに保存するんですね。
なので再起動したりすると消えるんですけど、その代わり早いと。
ただ、だから起発しても問題ないデータを格納していくという目的で使うものがキャッシングというところで、主にRedisとかMemcachedみたいなものが使われますと。
ありますね。大事。
で、もう次行っちゃおう。次はWebサーバーについてまいりましょうと。
Webサーバーっていうのは今はもうAPIの手前にいることはないんですけど、昔とかだとアプリケーションがウェブサイトを返すみたいなMPAの構成のサーバーも多かったので、そうなると静的なアセットとかをクライアントに返すみたいな実装をすることが大半でしょうと。
そうなってくると静的なアセットについてはサーバーが返すんじゃなくて、こういうサーバーっていうのはアプリケーションサーバーが返すんじゃなくて、
その手前にWebサーバーみたいなものを置いておいて、そのWebサーバーが返すことでアプリケーションサーバー側の負荷を下げるみたいなことが行われてたんですね。
なのでその時にNginxとかApacheみたいなものを使って制御することがありましたと。
ただ現状でもPHPとかだとApacheを使うことが多分スタンダードなんじゃないかな、ModPHPみたいなものを使ってPHPにアクセスさせるとか。
そうですね。PHPでも僕もあんまり触ったことないですけど、ララベルとかそれ自体がWebサーバーとして機能するもの以外は基本的にはApacheに組み込む前提なのかな、なんでしょう。
最新のPHP知らんかな。ただもちろんAPIサーバーの例えばメンテナンス対応とかメンテナンスっていうのは指定の時間はもうアクセスできませんみたいな対応の時のために手前にNginxとか置いておいて、
Nginxの方でもうリクエストが来たら全部500とかで返しますよみたいな感じの設定をすることでアプリケーションサーバー側に何の影響も与えないようにするみたいな感じでできたりもするので、
アプリケーションサーバーの手前にWebサーバーを置いておくという構成はまだまだあるので、ずっと知っておくといいよねみたいな感じですね。
データベースの基本
はい、そして続いてもっとデータベースについて知ろうという回ですね。
もうアバウトデータベースですね。データベースの座学というかいろいろな知識が出てきますね。
そうですね。皆さんさっきリレーショナルデータベースのところでとりあえずデータベースにデータを格納するっていうことは学んだと思うんですけども、
いわゆるSQLをですね、そのまま使うっていうことはしませんと。それはいろんなセキュリティ的な問題であったりだとか、そもそも使いづらいっていう問題があったりとかするんで、
一般的にはORMと呼ばれる、ORマッパーかな、オブジェクトリレーションマッパーかな。確かそれにあってますね。
そういうものを使ってデータベースのデータとアプリケーションで扱いたいデータって型が違ったり形が違ったり、結構違う類のものだったりするので、そこをうまくつなぎ合わせてあげるための仕組みとしてORMというものがあったりしますと。
そうですね。Goだと例えばゴームとか、Rubyだとアクティブレコースとか有名なものはいくつかありますね。
もちろんORMはマストじゃないので使わなくてもいいんですけれども、使うケースがあるかなと思います。データベースに関しては基本的にアシッド特性と呼ばれるものがあったりしますと。
これはリレーショナルデータベースがリレーショナルデータベースたるゆえんの仕組みというか、仕組みっていうか満たすべき特性ですね。
アドミシティ、コンシステンシー、アイソレーション、デュラビリティみたいなのあるんですけど、ちょっとその細かいところは端折りますが、基本的にはそういうものがあって、まずはこれは皆さんお勉強しておいてください。
これによってですね、データベースにはトランザクションと呼ばれる複数のテーブルだったりだとか複数の列とかを更新する際に、他の並行して行われる通信と通信というかデータベースへの読み込み書き込みに対して、
何かあったとしても問題ないような動きを実現することができる。ちょっと厳密に言うとアイソレーションレベルとかいろいろあるんですけど、ちょっとそんな難しいことは置いといて、データベースを安心して使えるようにする仕組みがあったりだとか、
データベースのテーブルをどういう感じでデータを置いていくかっていう正規化の仕組みであったりだとか、性能の話とかすぐ細かいのがいっぱいあるんですけど、
そういうデータベースの細かいことについても考えていきましょうとか勉強していきましょうみたいなところがここに書かれています。
メッセージブローカーの重要性
それが終わるとあとテスティングで。テスティングもユニットテスト、インテグレーションテストとかいろいろあるんですけど、いわゆる簡単なロジックに対するテストもあればAPIレベルのテストもあったりします。
急にコンテナライゼーションっていう、コンテナとかコンテナのオンケストレーションのところが入ってきたんですけど、むずくないか?
最近のプロダクト開発というかバックエンド開発においては基本的にAPIサーバーを作ったらコンテナで動かすことが大半なんですね。
なので自分たちでDockerファイルを書いたりとかすることも多いと思うので、APIサーバーをコンテナで動かすための仕組みだったり、
そもそもコンテナってなんだっけとか、コンテナを本番環境で運用する場合にはどういったツールを使う必要があるんだっけみたいなことを学ぶ必要があるらしいです。
この前Docker会も取ったので、詳しくはそこでいわゆる話です。
で、それ触ったらメッセージブローカー。
メッセージブローカーってなんだ?ちょっと待ってくださいね。メッセージブローカー。
メッセージブローカーっていうのは非同期の処理を作るための一個の仕組みで、システムとかアプリケーション間でメッセージを仲介するミドルウェアというかソフトウェアなんですけど、
まず前提としていわゆるAPIサーバーっていうのは同期的な通信をクライアントに対して行うものが大半なんですね。
なんかAPIリクエスト投げたらサーバーで処理して終わったら返すって仕組みなんですけど、サーバー間の通信って必ずしも全部同期的じゃないですね。
そうですね。
で、ツインにある概念を非同期って言うんですけど、それは何かリクエストを投げて別に終わることを別に待たないと。
何だったらコールバックみたいな感じで向こうから終わったよって言われてから始めて確認しに行くケースもあれば、
自分の中でスリープして一定時間後に取りに行くとか、いろんなケースがあるんですけども、
その非同期の仕組みを作りやすくするためのツールがメッセージブローカーで、ラビットMQとかカフカっていうものがまずありますと。
なるほど。僕はカフカの名前だけ知ってたんですけど、なるほどそういうものだったんですねという、綾田いけるんです。
例えば自分、SNSだとして、自分のところにフレンド申請みたいなものが届いたケースを考えたいんですけど、
ユーザーがフレンド申請を送るみたいなところは、フレンド申請のAPIを叩いて終わりなんですけど、そこから相手に通知を送るってところを考えたいですと。
その時に別に何も考えなければ、別にフレンド申請の裏で同期的にその相手に対して通知を送るっていうこともありなんですけど、
ちょっと数が多くなってきたりとかですね、例えばリツイートしたやつを、自分のことをウォッチしてくれてる全員に対してそのリツイートしたツイートを全員のタイムラインに載せるみたいなことをやろうと思うと、
例えば人の数によっては凄まじい数の通知をいっぺんに飛ばさないといけないみたいなことがあるじゃないですか、こういう通知っていうのはタイムラインに挿入するみたいなぐらいのイベントの話ですけど、
そうすると、そうありそうで、例えばそれを処理するときに1回メッセージブローカーと呼ばれるイベントを受け取るところに渡して、
こいつはメッセージブローカーの性質によるんですけど、AWSでいうと、Google Cloudでいうとクラウドカブサブが近いんですけど、サブスクライブやパブリッシュみたいな関係を表すとわかりやすいんですけど、
何かのサーバーがこの人がこれをリツイートしましたっていうイベントをブローカーに投げて、それをサブスクライブしてるいろんなサーバーがリツイートされたという情報を受け取れるんですね。
これは性質によるんですけど、1回受け取ったらどっかのサーバーが、他のサーバーも受け取れないっていう設定もできるし、サブスクライブしてるサーバーは全員が同じメッセージを受け取れることもできるんですね。
そうしたときに、サブスクライブしてるサーバーがリツイートしたというものを受け取ったら、それに応じて自分たちが必要な処理をやって、後続の処理に渡すみたいな形で、
伝搬させていくこともできるし、どっか1台が責任を持ってやることもできるし、そういう仲介役のような機能を持ったりしますね。
なんか今の話を聞いてて、いわゆるQ、例えばAWSのSQSみたいなものもメッセージブローカーの一部というか、メッセージブローカーと言えるんじゃないかなと思ったんですけど、それは違うんですか?
確かに、言えるっちゃ言えますね。
でもメッセージブローカーとしても、例えばそういうQみたいな必ず詰まれたら、必ずこいつにQ自身から投げるものもある、ちょっと厳密にはあれか、コンシューマーの方から受け取るみたいな協力だと思うんですけど、
メッセージを仲介するっていう役割を担う上でも、いろいろな形式があるっていうんですね。
CI/CDとサーチエンジンの理解
そうですね、確かにそういう意味ではAWSのSQSはブローカーと言えますね、定義上は。
そうですね、まあまあまあ、でもそういうものだと理解します。
次にCI、CDがあって、これはいろんなものがあるんですけども、CIっていうのは継続的なインテグレーションのことで、CDじゃなくて継続的なデリバリーのことなんですけども、
インテグレーションっていうのはすごいわかりやすい具体例で言うと、ギター部でプロリック作った時に、そのコミット単位でテストを流したり、リントしたりとかフォーマットしたりとか、
そういう開発に関わるものに対して自動化して、まあいい感じにしていこうという仕組みのことで、
CDの方は作ったものをデリバリーするところ、バックエンドにおいてはサーバーを開発環境とか本番環境にデプロイすることのことを指しますね。
このギター部アクションとか、サークルCIとか、クラウドビルドとか、そういうものを使って組んでいくっていうのがCI、CDのところですね。
その後、サーチエンジン、本当か? サーチエンジンは全文検索エンジンとよく日本語では言うんですけども、
また具体的に言うと、クックパッドみたいにいろんな料理の作り方みたいなものを検索して、一番マッチしたものを表示するっていう仕組みがあると思うんですけど、
ああいうものを管理する検索エンジンになってます。 そうですね。たぶんあれですよね、RDBよりも全文検索によったというか。
そうですね。RDBと違って、入力された文言に対して字とか句っていう単位での解析を行って、それのマッチ度みたいなものをうまく測定して出すっていうものになっていて、
もちろん今RDBとかPOSGLEとかでもそういう全文検索の仕組みがあったりするので、最近ちょっと垣根が若干怪しいんですけど、
垣根が怪しいっていうか、POSGLEとかはいろんなこと手広げてるからそうなってるだけですけど、サーチエンジンという領域は割と一大領域みたいなところがあるので、別にバックエンドエンジニアじゃないだったら知ってるべきみたいな感じはちょっと違うかもしれないですね。
アーキテクチャーパターンの重要性
そうですね。あとサーチエンジン、それこそエラスティックサーチとかはもう一つ何だろう、リコメンデーションみたいな文脈でもよく使われるというか、そうですよね。
よく登場しますね。続いてアーキテクチャーパターン。
アーキテクチャーパターン、みんな大好き。
フロントエンドだけ登場しなかったのに、アーキテクチャーパターン。
確かにフロントエンドの設計なんてみんなもう気にしてないですかね。
そんなことないでしょ。
でもやっぱりあれですね、デザインパターンとかそういうものってサーバーから生まれたものですもんね。
何だっけ、有名な、それこそクリーンアーキテクチャーだったりとか、もともとデザインパターンってJavaで書かれてたものじゃないですか。そういうものとか。みんな大好きなやつですね。
ここで言うアーキテクチャーパターンはアプリケーションの分割方式に関する話と、
アプリケーションの中のコードをどう表現していくかって話のたぶん2つが混ざっていると思っていて、
前者の方はいわゆるモノリスって呼ばれる、すべてのコードベースを1個にしちゃってクソでかいアプリを作るって話だったり、
モジュラーモノリスっていうモジュール単位で構成を分けるって話だったり、
さらに分割してマイクロサービスって呼ばれる、役割ごとにプロセスを分けちゃいましょうみたいな、そういうものっていうアプリケーションの分割レベルのアーキテクチャーの話と、
オニオンアーキテクチャーとかレイヤードアーキテクチャーとかクリーンアーキテクチャーとか呼ばれるアプリケーションの中でのコードの表現として、
どうすれば依存性の逆転が起きにくくなるかとか、どうしたらドメインをあまり汚さない設計にできるかとか、
そういうスパゲティコードだったり、トランスクリプトとかを、トランザクションスクリプトかな、生まないようなコードを書けるかみたいなことを考えるアーキテクチャーの話の2パターンですね。
データベースのスケーリングと運用
そうですね。面白いパターン。
これができると次はリアルタイムデータになって、リアルタイムデータは通常普通のクライアントとサーバーからの通信はリクエストをパナーで送って返ってきて終わりみたいな感じなんですけども、
そうじゃなくてずっとつなぎ続けておいてストリーム形式でデータをもらうような形、ストリームじゃないですけど必ずしも、サーバーサイドイベントとかサーバーセントイベントか、
ウェブソケットとかクライアントから張るロングポーリングとか、あとはGRPCのストリームとかいろいろ種類はあるんですけれども、そういうものを使ったりするケースもありますと。
そうですね。
それができたらスケーリングデータベース、データベースのスケールか、データベースはRDBの場合って基本的な構成としてはクラスター構成っていうものを組みます。
クラスター構成っていうのはデータベースを2台用意して1台がプライマリーと呼ばれるもの、2台目がセカンダリーと呼ばれるもので、基本的にはプライマリーに対して基本的に書き込みとか読み取りを行っていきますと。
これがダウンした時に困るからもう一つの方がダウンした時はプライマリーに昇格して書き込みや読み取りを受け取るという感じなんですね。
そうですね。あとプライマリー、いわゆるセカンダリー側の方にリードヘビーな処理を任せるとそういうこともやりますよね。
そうですね。あとはリードレプリカっていうリード専用のデータベースを作ってリードは全部そっちに寄せるみたいな構成もまずあったりしますと。
ちなみに昔撮った回に僕がリードレプリカの方にデータを送るために多少ラグが発生する、それがレプリケーション遅延って呼ばれるやつですけど、僕のやらかしによってレプリケーション遅延に3分を越したっていう話も撮ってるので皆さんぜひ聞いてください。
データベースのそういったRDBのスケールアップはスケールアップっていうのが基本なんですね。スケールアップっていうのはCPUとかメモリーとかディスクとかをほとんど増やしていくっていうパターンなんですけど、これもどっかにスケールの限界がありまして特にクラウド環境だと最大のスペックとかが決まってるのでそれ以上のサイズには増やせないっていう上限がありますと。
なのでその時に使う仕組みとしてシャーディングっていう方法があるんですけれども、これは多分垂直シャーディングと水平なシャーディングと2種類あって、自分はそんな経験ないんですけど、例えばユーザーテーブルで考えると1番から1万番はデータベース1番に保存して1番以降はデータベース2番に保存するみたいな感じで、
IDの何番か何番単位で分けるやつですね。多分これが垂直なスケーリングのはず。水平なスケーリングはもうIDの例えば1番2番3番っていうのを例えばですけど、モッドの4とかで割って、そうすると余りが0、1、2、3になるじゃないですか。
なるほど。 なので4台のデータベースにそのモッドの値で分散して書き込むみたいな。 なるほどなるほど。なんかそっちの方が終わりが見えないデータに対しては向いてそうですね。
でもあれは途中で5台目増やしたいとき大変ですけどね。 確かに。スケーリング自体に弱い。それはありそう。
はい、っていう感じでデータベースのスケーリングがありますと。キャップの定理であるのは、これNewSQLの話なんですけど、NewSQLは、NewSQLだけじゃないのかな。
NoSQLもあるのかな。NewSQLとかだとディレーショナルデータベースみたいなトランザクションが張れるのに、なんか事実上半無限に横に展開できるみたいな、スケールできるみたいな。
いろいろ難しいPAXOSのアルゴリズムがあったりとか、すごい正確な時刻があったりとか、いろんな前提条件はあるんですけど、そういうものがあってうまいこと成り立ってますと。
その次にNoSQLデータベースがあって、NoSQLデータベースは、NoSQLって書いてるんですけど別にSQLみたいなものは叩けるんですけど、今までのデータベースとは全然違う概念で動いていて、
B3じゃないですよね、確か。そもそも。LSMなのかな。ちょっと忘れちゃいましたけど、そのスケールデータベースってのがあって、うまいこと進めていけないな。
なんかこれもスケールにすごいできるし、テーブルの中でキーマ定義があんまりいらない、ないに等しいのかな。本当に自由に列が作る、列やカラムが作れるんですよね。
そういうものが多いですね。NoSQLってこのシリーズ、無限に例を出せそうなりするし、なかなか一言でくくるのが難しい概念ですね。
そうですね。なんで、すごい柔軟なスキマと高いスケーラビリティができるもので、非構造化データとかビッグデータにすごい適しているデータベースになっています。
ここまで来ると、ベーシックオープンベーシックス。
ここまででやっとベーシック。
ベーシック来たか。
まあまあいろんなこと詰め込みなせんでしたら、そうですね。
違うか、違うわ。次はさらにベーシックな運用スキルの話になってて、LinuxとかネットワークとかAWSがテラフォームとかデジタルアプションとかそういうの触れるようになりましょうねっていうのがまとめても書いてある。
なるほど。確かにもう少し実務に寄った構成なものが出てきましたね。
なんでここのベーシックオープレーションスキルが手に入ると、LinuxとかネットワークとかAWSが触れるようになりますよっていうのが丸めて書いてありますね。
丸めすぎてないか。まあまあでもこの辺りの今ここに出てる技術は割となんか現場に入ったらすぐ一通り触りそうなものでもありますね。
はい。で、最後にスケールのためのビルドみたいな話で、オブザーバビリティの話とリティゲーションストラテジー。
ああ、あるか。システムをスケールさせるためにこういうことを知っておくとすごく便利だよみたいなものたちですかね。
まずオブザーバビリティからざっくりいきますけど。
ああ、そうだ。専門家がオブザーバビリティの。
果敢属性と日本語で訳されますが、システムが今どういう状態でどういうとこにボゾルネックがあって問題があるのかっていうものを
システムの緩和戦略
わかりやすく可視化するための仕組みとかツールとかそういうの全般を指しますと。ログとかテレメトリーとかイベントとかそういうものを受け取って作ります。
で、もう一個が緩和戦略って書いてあるんですけど、グレイスフルディグラデーションって何?
あーなんだっけ、グレイスフルディグラデーション、ディグレデーション。
システムに何らかの機能不全や負荷が発生した時にサービス全体を停止させるのではなく、重要な機能を維持したまま限定的な状態に移行させることで影響を最小限に。
あのー。
ソーリーページとかそういうこと?
そうですね。まあなんというか、不具合が起こった時の設計どうするかの一つですね。
はい。
スロットリング。
スロットリング、まあこれはなんかAPIとか対応に戦えた時に一定の回数以上叩いたユーザーはちょっとブロック数とかそういう感じで敷地をコントロールするってやつですね。
そうですね。
まあそういうこともAPIゲートでやったりします。
そうですね。
次はバックプレッシャーは?
バックプレッシャー、フローコントローラー。
システムやネットワークにおいて処理能力が速い送信側が処理能力の遅い受信側を圧倒してリソースを使い果たすのを防ぐための制御方法ですって書いてあって。
これ多分よく聞くのはKubernetesのマイクロサービスにおけるポット管の通信でいっぱい送っちゃうと受け手側が429みたいな2バッチ、2BDリクエストとかでエラー返すパターンがあると思うんですけど、
ああいうところにサーキットブレイカーみたいなものを置いて、ある程度リクエストが来たらもう弾いちゃうとか、送る側も自分で送る量流量制御したりとかそういうコントロールするみたいなことをやったりします。
本当にこれここにマイクってもいいと思うんだけどな。なんでこのロードマップこんなに大変なの。
ちょっとここまで来たら限定的な知識になります。使いどころがロードシフティング、サーキットブレイカー。
ロードシフティングは何なのこれ。ロードシフティングって何。
ロードシフティングマネージーズコンピューティングマークロード。つまりそれこそさっき言ったリクエストを送り手側で制御するみたいな話じゃないですか。
あれなのかな。時間帯によってリソースサイズを増減させてコストカップをしましょうみたいな話なのかな。
そうか。それこそオートスケーリングにある程度今なら任せられる話かもしれないですね。
そうですね。オートスケーリングもやっぱり即時性が低いみたいなところもあったりするので、難しいかもしれないです。
昔僕がソシアゲの現場にいたときに即時性がどうしても悪いので、イベントを始める15分前から徐々にニーマムを増やしていくみたいな制御を手でやってたことありますね。
多分そういうことなんでしょう。
最後がサーキットブレーカーでさっきその説明をしていました。ちょっと違うのかなバックプレッシャー。
バックエンドエンジニアの成長
バックプレッシャーは受信側・送信側に自身の容量を通知することでシステムの過負荷を防ぐフロー制御メカニズムです。
使ったことないな。そういう概念あるんだ。学びがありました。
はい。
はい。ということでここまでできたらあなたは一人前のバックエンドエンジニアということで。
なんかいやわかんないですけどもう少し何か別で学ぶことないのかなっていうのはちょっと気になりますね。
多分これGoとかにロードマップあるんですけど、Goのロードマップに飛んだらGoの言語としてこういうの作れたらいいよねみたいな話があるんで。
そっちもちゃんとやる必要がある。
そうですね。そうか。それこそGoでサーバーカクトだったら例えばGoルーティンとかそういうなりにGoに特化した技術が必要ですもんね。
そうですね。割と今話した内容ちょっとSREの様子とかも結構入ってきてですね。
なんかジュニアなバックエンドエンジニアにこれをちょっと要求するのは非常に酷だと思いますので。
まあやってもなんかどこまでだろうなコンテナライゼーションぐらいまででいいんじゃないかな。
データベースやってキャッシュやってテスティングやってコンテナまで。
確かに。あとさっき言ったようにこのバックエンドのロードマップと並行してGoのロードマップも進めるとかするとバランスいいかもしれないですね。
はい。そうですね。ちょっとなんでGoとかそういうのは今後機会があれば見ようと思います。
はい。ということで今回はちょっとバックエンドのロードマップを眺めていきました。
ちょっと途中からほんまかって思うことが多かったんでだいぶ怪しいですが、ちょっと僕らのリアクションを参考にこれは後でもいいかなというね気づいていただければいいかなと思います。
はい。このポッドキャストはハッシュタグライティで皆様からの感想やコメント募集しております。またチャンネルの概要欄にありますGoogleフォームのリンクからもご投稿可能です。ありがとうございました。
ありがとうございました。
