見出し画像

私たちは話し合う必要がある...

AGIに仕事を奪われたい

36,584 文字

サーバーレスの大ファンであることは周知の事実です。たとえ最近サーバーレスから移行する理由について動画を公開したとしても、全てを移行するわけではありません。実際、upload thingのために構築した新しいサービスもあります。基本的に私が構築するものは、依然としてサーバーレスのパラダイムに基づいています。しかし最近、その理由を詳しく説明したり、サーバーレスの真実を紹介したりする時間を取っていませんでした。また、特定のスポンサーがいない状態でそれを行うこともできませんでした。彼らがサーバーレスについて私が話すことに意味のある影響を与えることはありませんでしたが、より信頼できる会話ができればと思います。サーバーレスアプリケーションの構築について、人々が理解していることと理解していないことがたくさんあるからです。また、サーバーレスアプリケーションやサーバーレスマインドセットが、ほとんどのソフトウェア開発者にとって本当に素晴らしいものとなる理由について、人々が見逃している面白い秘密もいくつかあります。
とはいえ、今日もスポンサーがいないわけではありません。今日のスポンサーはPrismaです。おそらくORMとして知られていますが、実は今日利用可能な最高のデータベース製品の1つを持っていることをご存知でしょうか。最近まで知らなかったPrisma Postgresについて、その素晴らしさに驚かれるかもしれません。3クリックでデプロイできると言っているのは誇張ではありません。データベースのセットアップに関して、Vercelレベルの開発者体験を提供しているのです。そして無料枠で5つのプロジェクトが利用できるのは驚きです。それは無料でホスティングできるデータベースとしてはかなりの量です。
また、これまで見たことのない素晴らしい機能もいくつか備えています。例えば、commandキーを押してFキーでキャッシュを検索してみてください。データベースレベル、ORMレベルでキャッシュ戦略を設定できるので、その値を取得するためにデータベースに接続する必要すらありません。エッジネットワーク上で即座に取得できるのです。とても素晴らしいですね。また、VercelやNetlifyなどでホスティングする私たち向けにサーバーレス対応もされているので、サーバーへの負荷を気にする必要はありません。本当に素晴らしい製品です。
さらに、サーバーでリアルタイムの更新が必要な方向けに、データベースで何か変更があった時の対応もカバーしています。結果をストリーミングできるので、Prisma.user.streamを呼び出すだけで、何か変更があるたびにイベントストリームでレスポンスを受け取ることができます。これはとても素晴らしいですよね。これらの機能を自分でセットアップするのは楽しくありません。ORMをデータベース自体とこれほどうまく統合し、ほとんどのサービスに不可欠な機能を提供するサービスを見たことがありません。
PRとPostgresのスポンサーシップに感謝します。soy.link/prismadBで今すぐチェックしてください。
サーバーレスの真実について、これは複雑なトピックになります。深く掘り下げる前に、そして確実に深く掘り下げますが、まずサーバーレスの概要について簡単に説明する必要があります。サーバーレスをよく知っているものの、その良い点と悪い点の詳細を必ずしも理解していない方は、ぜひ最後までお付き合いください。
明らかに、サーバーレスはサーバーがないということではありません。それは、アプリケーションやコードのためにサーバーをプロビジョニングする必要がなくなったということを意味します。
私が子供の頃にクールだった従来のLAMPスタックで構築する場合を考えてみましょう。LAMPスタックはLinux、Apache、MySQL、PHPの略です。LAMPスタックで構築する時は、これら4つすべてを同じサーバー上で実行していました。Linuxを実行しているサーバーがあり、HTTPリクエストを調整するトップレベルとしてApacheがあり、ページを生成する実際の作業を行うPHPがあり、データを取得・書き込むためのMySQLがありました。データベースが何をするかはご存知でしょう。
その後、MEANスタックが登場しました。これはMongoDB、Express、Angular、Nodeのことです。この時点から、すべてを1つのサーバーで実行するという考え方は、特定の企業、AWSの影響で薄れ始めました。
以前の方法では、このように動作していました。古い方法と呼びましょう。ここにボックスがあり、これはLinuxを実行しているとします。このボックスの最上位にはApacheのような何かがあり、同じサーバー上の別のレイヤーにPHPがあり、最後のレイヤーには同じサーバー上にMySQLがありました。
ここで私の図の描き方を考え直してみましょう。LAMPスタックで説明したように、これらすべてを異なる要素として描きましょう。このボックスを1つのサーバーとして考えてください。そこではApache、PHP、MySQLがすべて実行されています。PHPコードを交換したい場合は、FTPでアクセスしてPHPコードが呼び出すファイルを置き換えることで行いました。PHPはインタープリタ型なので、PHPファイルを異なるPHPファイルに置き換えるだけで問題ありません。
しかし、興味深いことが起こりました。実際には2つのことが起こりました。私たちが構築に使用する技術が少し変わりました。Apacheは使用するかもしれませんが、通常は気にしませんでした。MEANスタックではExpressとNodeを使用しました。Angularもここにありましたが、Angularコードはこのサーバーでは実行されませんでした。Angularコードは、Expressが解決するHTMLの一部としてのスクリプトタグでした。そしてそのスクリプトタグは、実際のAngular側やReact側を実行するために、おそらくS3のような場所からロードされていました。
しかし、ここで急速に何かが起こり始めました。JavaScriptのコードを交換するためのツールが複雑になりすぎて、単にFTPでアクセスして交換するのは非常に信頼性が低くなったのです。さらに、うまく動作させるのも面倒でした。
この状況と、皆さんもご存知かもしれないAWSという小さなスタートアップ企業の組み合わせにより、興味深いことが起こりました。彼らはこれを分割しました。すべてのものが入った1つのサーバーを持つ代わりに、ExpressとNodeコードだけを持つ1つのサーバーと、コードだけを持つ別のサーバーを持つようになりました。
これにより、多くの素晴らしいことが可能になりました。これを変更してもデータベースの整合性を危険にさらすことはなくなりました。もし多くのトラフィックを処理するためにより多くのボックスが必要な場合は、単に多くのボックスを実行し、それらがすべて同じデータベースに接続していれば問題ありません。
徐々に、他のデータベースでもこれを行うようになりました。初期の段階からMySQLだけではありませんでした。データベースプラットフォームがアプリケーションコードとは別に実行されるサーバーであるという概念は、ある時点では新しい考え方でした。APIでデータベースの読み書きを処理する主な方法として、どこか別の場所にあるデータベースに接続するという考え方は奇妙でした。当時の人々はそれに慣れていませんでした。
最終的には、これはマイクロサービスにまで発展し、異なるExpressとNodeのコードベースが全く異なるボックス上で実行され、すべてが何らかのデータベースを真実の源として使用するようになりました。
なぜこれを行ったのかという大きなきっかけの1つは、これらのボックス上で実行されているコードを交換する能力でした。これがGoコードを実行している場合、これがPythonコードを実行している場合、または他の何かを実行している場合、PHPのように実行中にコードを交換する能力はありませんでした。このコードを適切に交換する唯一の方法は、新しいコードを持つ新しいサーバーを起動し、そこにトラフィックを向け始め、古い方のトラフィックを停止し、その後このボックスを停止することでした。
ユーザーがアクセスしているボックスの中身を交換するためのこの種のセットアップは、ますます複雑になっていきました。さらに、以前はMySQLでここに保持していたような状態の多くが外部に移動し始めました。サーバーが停止した場合にデータが失われる状態を持つサーバーを実行する代わりに、いつでもサーバーを停止しても何も失われないようにし始めました。
しかし、その時点で、長時間実行されているサーバーを持つことからどれだけの利点を得ているのでしょうか？そして、巨大なトラフィックスパイクが発生し、このサーバーが持つプロビジョニングよりも多くが必要になった場合はどうなるのでしょうか？
みなさんお気に入りのKubernetesがここで登場します。Kubernetesは、これらの異なるサーバーをすべて管理することを非常に簡単にするために作成されました。それらがいくつあるのか、どのコードを実行しているのか、EC2でのAutoスケーリンググループも大きな部分でした。Ryanからの良い指摘ですね。こんなに詳しく知っているとは知りませんでした。そうですね、EC2は別の道でした。その後、ECSとEKSもすべてこれらのKubernetesプリミティブを中心に構築されました。
目的はすべて同じでした。特定のコードを特定のサーバーが実行していることについてあまり考えなくて済むようにすることです。代わりに、サーバーを起動する能力を設定し、データベースが分離されている限り、いつでもサーバーを起動したり停止したりできます。誰も気にしません。1台のサーバーを持っているか100台のサーバーを持っているかは、それらがすべてデータベースに接続していれば問題ありません。実際、持っているサーバーの数は重要ではありません。
私はRyanのことを何でも知っていると仮定することを学びました。それは通常正確です。はい、しかし私が経験した最高の栄誉の1つは、Ryanの頭の中で何かがクリックするのを助けたことです。彼のように本当に何でも知っている人に、たまたま理解していないことを理解させることができたのは、魔法のようです。彼らがそれを経験していないために理解していないことを理解させることができるのは、本当に謙虚になります。
そうですね、Ryanがこれほど多くのことを知っている大きな理由は、彼が学ぶ時間を取り、より良く知っている人々と話し、学び、間違いを認める意志があるからです。しかし、彼は何でも知っているように見えます。
とにかく、テクノロジーの中の別の賢いものであるKubernetesの説明に戻りましょう。Kubernetesについて触れ、その言葉を書き出すことで、皆さんに少しトラウマを与えたことを願っています。私のブランドとチャンネルで推進しようとしている特定のことの1つは、大企業の特定のタイプのワークロードにとって機能するこれらのものを取り上げ、平均的な開発者がそれらに触れるべきでないことを確実に知ってもらうことです。
100%のコードカバレッジやKubernetesのようなものは、特定の大企業では理にかなっているかもしれませんが、中小規模の企業や、大企業の中小規模のチームの大多数にとっては、はるかに意味が少なくなります。
誰がこのことに気付いたと思いますか？AWSです。ここまでの文脈を整理しましょう。最初は1つのボックスにすべてがありました。次に、データを失うことなくこれを交換できるように、アプリケーションコードとデータベースレイヤーを分離しました。そして、これらの複数を同じデータベースに接続して実行でき、どれでも問題ないことに気付きました。これはスケーリングがはるかに容易になり、Nodeを実効的なものにしました。
ここで指摘しておくべきなのは、Nodeの同時実行モデルは、I/O束縛のタスクには優れているものの、重い処理には向いていないということです。そのため、複数のサーバーをスピンアップできる機能は、特にNodeにとって非常に有用でした。
しかし、ここでAWSで明らかになり始めたことがあります。なぜ私たちは、実行するサーバーの数について考える必要があるのでしょうか？そしてなぜそれらすべてを常時実行する必要があるのでしょうか？
理論的なシナリオを設定してみましょう。ここで簡単な図を描きます。これがユーザー数を表し、下部は時間を表すとします。会社が始まった時、ユーザー数は比較的少なく、1台のサーバーで快適に対応できました。ここにいくつかの閾値を設定してみましょう。この線は1台のサーバーがもはやトラフィックを処理できなくなる点です。これが2台のサーバー、これが3台、これが4台となります。
長い間、これで問題ありませんでした。しかし、初めて閾値を超えた時に物事が複雑になり始めます。そして今、2台のサーバーが必要になります。例えば、ブラックフライデーのような特定の時期にだけ、そのようなトラフィックスパイクが発生するとします。
これにより、1台のサーバーでは対応できないほどのトラフィックが発生するので、2台必要になります。自動スケーラーを設定して、トラフィックが特定の閾値に達した時を検出することができます。通常、それはここに閾値を設定し、トラフィック、ユーザー数、または追跡している指標が特定のポイントに達した時に、別のサーバーをスピンアップします。
そのポイントを超えた場合、トラフィックを処理するのに十分なサーバーを持つことになります。これは同時に、複数の場所で実行でき、同じボックスに接続された複数のユーザーについて前提を置かないようなコードを書く必要があることも意味します。
しかし、これらすべての前提を置き、ステートレスな方法で構築し、何かがスケールアップやダウンすべき時を検出するための閾値を構築すれば、これを処理できます。問題は、それがスピンアップするのにかかる時間です。
これをコピーペーストして、もっと面白い例を見てみましょう。ブラックフライデーによるゆっくりとしたランプアップの代わりに、TheoがTwitterで言及したり、動画で紹介したりしたことによるランプアップを考えてみましょう。その代わり、ランプアップはこのように見えるとします。
数秒で、少数のユーザーから3倍以上に瞬時に増加します。この閾値を超えたので、次のサーバーをスピンアップしますが、2台のサーバーが必要だったことを認識する能力さえあるでしょうか？サーバーがスピンアップするには時間がかかり、どれだけのトラフィックが来ているかを知るのに十分なサーバーを持っている必要があります。
閾値を超えた場合、その閾値をどれだけ超えたかを必ずしも知ることができません。そのため、スピンアップするサーバーの数が複雑になります。その結果、多くの企業が行っていたこと、そして今日でも多くが行っていることは、私自身もAmazonで guilty of this でしたが、理論的なピークまでプロビジョニングすることでした。
1台や2台のサーバーを実行する代わりに、常に3台実行するのです。なぜなら、その代替案は、一部のユーザーがエラーページを受け取るか、サーバーが過負荷で不十分なプロビジョニングだったために接続がハングするかだからです。
これは最悪です。はっきり言わせてください。これを行うのは楽しくありません。もしあなたがこれを楽しいと感じるタイプの人なら、素晴らしいですね。その過程で私からたくさんのお金を稼ぐことになるでしょう。しかし、これは最悪です。
チャットで誰かが「JSを使わなければいい」と言ったのは面白いですね。なぜなら、他の多くの言語ではこれがさらに悪化するからです。RailsはI/Oをブロックするので、1人のユーザーのためにデータベースチェックを行っている間、次のユーザーはリクエストを開始することさえできません。少なくともJavaScriptでは、データベースが何かを行うのを待っている間、I/Oは他の処理をブロックせず、他のリクエストを処理できます。
GoやRustのような他の言語でこれを自分で構築することはできます。リクエストとは別に、ノンブロッキングI/Oを処理するための同時実行モデルを構築できます。しかし、この時点で、Rustで並行性とパラレル性を扱うのがどれほど悲惨かはご存知でしょう。
Rustコミュニティでさえ、これをほとんど認めており、これらの他の言語で並列処理やマルチスレッディングを正しく行うことがいかに難しいかについて、素晴らしいコンテンツを書いています。しかし、ノンブロッキングI/Oは難しい問題です。いいえ、Railsはこれを解決していません。
Railsには「Rack」という素晴らしいものがあり、1つのボックスで複数のスレッドをスピンアップできます。しかし、それらの各スレッドはI/Oによってブロックされる可能性があります。これは事実です。
信じられないかもしれませんが、JavaScriptは実際、このような環境で実行するのに非常に適した言語です。コードが非常に非同期になることなく、より簡単に扱い、理解できるという利点を考慮すると。私が見た中で、真に完全にスレッド化され、読みやすいコードベースは、Elixirで書かれたものだけでした。なぜなら、Elixirはこれらのことのために構築されたからです。
はい、もしあなたがRustを美しいと思うなら、十分な並行処理と非同期のRustを書いていません。なぜなら、そのコードでは美しさの多くをすぐに失ってしまうからです。
とにかく、この解決策を素晴らしいものにしたい場合、いくつかのことを行う必要があります。ここで、ロードバランシングの解決策を機能させるためのポイントを説明します。
サーバーが速くスピンアップできるようにする必要があります。トラフィックスパイクを処理する必要がある場合、サーバーがスピンアップするのに2分待つ必要はありません。それをすぐに必要とします。そのため、コールドスタート時間とサーバーのスピンアップにかかる時間は、はるかに重要です。
また、トラフィック量をより簡単に検出できるようにし、トラフィックパターンを追跡しやすくする必要があります。そして、もちろんコードをステートレスにする必要があります。
もちろん、Amazonはこれらすべてのことを行うために懸命に努力しました。新しいサーバーのスピンアップをできるだけ速くするために努力し、トラフィックレベルがどのように見えるかを実際に検出するための他のツールを使用しやすくしました。トラフィックを処理できるサーバーを持っていないことが、どれだけのトラフィックを受けているかを知ることを妨げないようにするためです。
そして、サーバーレスから状態を移動し、データベース製品や楽しい新しいサーバーレスデータベースソリューションなどに移すことを奨励しました。しかし、ロードバランス解決策をうまく機能させるためには、これらのことが誰も考えたことのないものから高優先事項になりました。
最近まで、PHPの世界では、PHPコードを初期化したり、ゼロからボックスをスピンアップしてPHPを実行させたりするのにかかる時間について考えている人はいませんでした。これらは人々が考えることではありませんでした。なぜなら、常にそこにある固定数のサーバー上でPHPを実行していたからです。
起動にかかる時間については考えませんでした。なぜなら、起動しないからです。17年前に起動して以来、触れていないのです。そのため、これらのことはほとんどの開発者が考えていなかったことでした。
しかし、これらのタイプのトラフィックパターンと動作を処理するために、AWSはこれらのことについて考える必要がありました。そして、十分に注意を払っている人々は、ここで何が起こったかを理解するでしょう。彼らは偶然にもサーバーレスを発明したのです。
サーバーレスは、これらすべてのことを行って、ロードバランスされたサービスがより速くスピンアップできるようにする努力を払った時に自然に発生しました。1台のサーバーから2台のサーバー、3台のサーバーに移行する必要がある場合、異なるサーバー上に異なる状態があるという事実に対処する必要があります。これらがほぼ即座にスピンアップする必要があるという事実に対処する必要があります。
どれだけのトラフィックがあるかを知る方法が必要です。そうすれば、スピンアップするサーバーの数を知ることができます。ここで導かれた明らかな質問は、「もし自動化されていたら？」というものでした。
これがサーバーレスが存在する理由です。ロードバランシングを自動化するプロセスは、自然にLambdaの再構築という結論に至ります。そして、サーバーレスがこのように機能する理由は、これらの問題を最適化しようとすると自然に行き着く場所だからです。
実際にサーバーレスとは何かを説明するために、なぜならもちろんサーバーはありますが、私たちはさらに抽象化を進めました。以前の分散MEANスタックの例に戻ると、サーバー1、2、3があり、これらのサーバーすべてがExpressとNodeを実行し、データベースがありました。
これを別々に移動させたいと思います。なぜなら、これらを明確な一連のものとして分離したいからです。以前に示していたものとは異なる方法で図を描く簡単な方法は、ステートフルな側とステートレスな側に分けることです。
このコードは実行され、終了し、そのすべてのケースを処理できる必要があるからです。そのため、状態をこちら側に移す必要があります。状態はRedisにあるかもしれませんし、他の多くの場所にあるかもしれません。
これらのサーバーが状態を必要とする場合、他の場所から取得する必要があります。なぜなら、このサーバーをいつでも停止したり、その横に別のサーバーをスピンアップしたりしても、ユーザー情報などを追跡し続ける必要があるからです。
そして、物事をこのように分離すると、次のステップはほぼ明らかになります。これをExpressコードに素早く変更し、より明確になるように少し大きくしましょう。なぜなら、このサーバーはExpressコードとNodeを実行しており、それがコードが実行されている場所だからです。
ここで、より多くのトラフィックが必要だと判明した場合、これらのボックスの全く別のものをスピンアップする必要があります。そして、これらのボックスはLinuxを実行しているので、Linuxが起動するのを待つ必要があります。
そこで、Linuxだけが入った空のボックスができました。それが起動したら、Nodeをスピンアップし、Nodeとそのすべての依存関係、その他すべてをロードする必要があります。そして、Expressコードをロードします。
そして、サーバーがそのコードを処理し、起動して実行を開始した後、これらすべてにかかった何秒か、場合によっては数分後に、あ、そうそう、データベース接続も形成する必要がありますね。物事を行うためにデータベースに接続する必要があります。
すべてのその作業が完了した後、このサーバーはようやくリクエストへの応答を開始できます。しかし、もしExpressコードを移動させたらどうでしょうか？もし、これらのサーバーがすべて、あなたのコードなしで既に実行されていたらどうでしょうか？
以前に示したように、これは自分で行うことができます。あなたが行うかもしれないすべての異なることや、到達するかもしれないすべてのユーザー数のために、適切な数のサーバーをスピンアップできます。しかし、それは非常に高価になるでしょう。しかし、Amazonのような規模であれば、そのような多くのサーバーをスピンアップして保持することはそれほど大きな問題ではありません。特にWebの半分程度のトラフィックを扱っている場合は。
なぜなら、1つのウェブサイトのトラフィックがスパイクしているということは、他のウェブサイトがそうでないことを意味するからです。そのため、これらのサーバーをすべて既に実行し、一時的に人々と共有できるようにすることで、効果的に同じ命令の異なるレイヤーとなります。
EC2を通じてサーバーをレンタルする時、彼らはサーバーラックに行って、あなたのために新しく購入したボックスを差し込み、それをあなたに割り当てているわけではありません。彼らは既にこれらのマシンの多くをスピンアップして、準備ができています。彼らは単にその中の仮想レイヤーをあなたに提供しているだけです。
そして、彼らがそれ以降行ってきたこと、つまりサーバーレスが実際に何であるかというと、さらに1段階高いレベルに抽象化したということです。今や彼らは、あなたのコードを取り込んで無期限に実行するのを待っているサーバーを持っているだけではありません。代わりに、ペイロードを待機しているすべてのこれらのサーバーを持っています。
ペイロードはDockerイメージかもしれませんが、一般的には彼らはそれを推奨しません。彼らのイメージを使用することを推奨します。なぜなら、彼らの事前にプロビジョニングされたサーバーを使用できるからです。今、ユーザーがリクエストを行うと、彼らはあなたのコードを移動し、リクエストを処理し、それを取り出すだけでよいのです。
これがサーバーレスを可能にするものです。サーバーがないということではなく、以前のモデルと同じ方法でサーバーを所有していないということです。以前のモデルでは、これらのボックスはすべて、AWSデータベースで見ることができるものでした。my-server-1、my-server-2、my-server-3というサーバーがありました。これらはあなたのものであり、あなたが消すように言うまで存在し続けました。
サーバーレスが意味するのは、もはやサーバーがないということではなく、あなたが所有する部分に実際のサーバーが含まれなくなったということです。なぜなら、サーバーはリクエストが行われる時だけ実行されるからです。それはSQSを通じてトリガーされたイベントかもしれませんし、S3にファイルをアップロードしてLambdaをトリガーしたかもしれません。これらのものの1つがスピンアップする理由は多くありますが、デフォルトではそれらは存在せず、あなたのコードはS3に置かれ、これらのサーバーの1つがリクエストを受け取ってそのコードをロードし、実行を開始するのを待っているだけです。
さて、良い質問に行きましょう。サーバーレスは、呼び出しごとに依存関係がインストールされることを意味するのでしょうか？事実上、そうです。おっ、AJがいますね。素晴らしい。もし私が何か愚かなことを言ったら、訂正してください。これらのものがどのように機能するかについて、非常に単純化した説明を試みていますが、もし私が何か明らかに間違ったことを言ったら、あなたは何について話しているか知っているので、訂正してください。
素晴らしい仕事だと。すごい。サーバーレスの神様が私が素晴らしい仕事をしていると言っています。ここまで良好です、みんな。これは実際に良い質問です。サーバーレスは、呼び出しごとに依存関係がインストールされることを意味するのでしょうか？
今のところ、はいと言いましょう。説明してから、完全には真実ではないことを示しますが、まずは、はいです。1分に1回程度の少数のリクエストを持つサービスがあるとします。リクエストが来ると、AWSはそのリクエストを見て、「このリクエストはこのURLのためのものなので、このコードを実行する必要がある」と言います。
明確にするために、コードベースからのすべてのノードモジュール、複雑なものなど、あなたのコードの依存関係をすべてスピンアップする必要があるだけでなく、追加の接続も形成する必要があります。もしExpressがJavaScriptコードでORMを使用していて、そのORMがデータベースやRedis、その他に接続する必要がある場合、それらの接続の形成には時間がかかる可能性があります。
なぜなら、再び古いサーバーフルの時代に戻ると、すべてが同じボックス上にあった時、PHPがMySQLに接続するのにかかる時間を気にする人はいませんでした。なぜなら、既に接続されているからです。誰も気にしません。
突然、私たちはそれについてもっと気にする必要が出てきました。なぜなら、それは今やあなたのコードが実行されるのをブロックする要因となるからです。もし5秒の接続時間があり、それが一度だけだったサーバーレスでは、突然それが1日に数百回、場合によっては数千回発生することになります。これは、あなたが構築しているサービスによって異なります。
これはまた、データベースへの接続のバランスを取る方法がより重要になったことを意味しました。例えば、Heroku上のデフォルトのPostgresデプロイメントは、最大接続数が10でした。10の接続が可能でした。なぜなら、彼らは常に接続されている1〜10台のサーバーを想定していたからです。
しかし、15人のユーザーがいる場合、15の接続を持つ可能性があり、ここで古いデータベース接続方法は崩壊し始めました。そのため、PG Bouncer、PG Pooler、そして異なるデプロイメント間で共有できる接続を保持する方法を抽象化し構築するためのこれらすべてのツールが登場し始めました。
しかし、前述のように、サーバーバックのロードバランシングもうまく機能させるために、これらすべてのものを既に構築していました。なぜなら、11番目のサーバーが現れた時に、データベースが10の接続制限を持っているために接続できないというのは本当に最悪だからです。
これらの問題を解決する必要がありました。しかし、それらの解決策をさらに進めていくにつれて、これをより実行可能にし、今や「サーバーレスデータベース」という用語は、少し馬鹿げて聞こえるかもしれませんが、実際にはそうではありません。それが意味するのは、あなたのデータベースが実行されているサーバーが、途方もない数の並行接続を処理する準備ができているということです。
なぜなら、1500人のユーザーがいる場合、たとえそこからあまりデータを読み書きしていなくても、データベースへの1500の接続を持つ可能性があるからです。これは恐ろしく聞こえますよね。なぜこんなことをするのでしょうか？
しかし、これを考えられるほど悪くないものにする1つの要素があります。このコードが応答する時、このボックスは即座に死ぬわけではありません。しばらくの間留まり、あなたが作成した接続を保持します。そして、十分に早く別のリクエストが来た場合、それを処理します。
つまり、このコードを移動するコストを支払う必要がなく、コードをJITし、実行を開始し、データベースに接続し、そのすべてのことのコストを支払う必要がありません。それは既に支払われており、次のリクエストのために待機しているだけです。
そして、十分なユーザーと十分な相対的なトラフィックがある場合、コールドスタートに遭遇する回数はかなり減少します。しかし、トラフィックスパイクがある場合、トラフィックが減少してから再び通常に戻る場合、または単に既存のLambdaを飽和させている多くの人々がいて、誰かが現在のプロビジョニングを超える追加のリクエストを行う場合、コールドスタートが発生します。
そのため、それらのコストをできるだけ削減する必要がありました。そして、データベース接続のスピンアップコスト、JavaScriptコードのインスタンス化コスト、これらの多くのものは大幅に削減されています。そして今、サーバーレスで実行し、正しく設計されている場合、驚くほど優れたパフォーマンスを得ることができます。
これらすべてを分解したところで、この動画で実際に話したいことにようやく辿り着けたと思います。それは、サーバーレスがどのように機能するか、あるいはどのようにここに至ったかということではなく、ここのタイトル、サーバーレスの真実です。
真実について話しましょう。私たちが確立した事実について話しましょう。まず、サーバーレスは高速な起動時間を必要とします。2つ目に、サーバーレスはゼロにスケールします。3つ目に、サーバーレスはアプリケーションコードのステートレス設計を必要とします。そして4つ目に、サーバーレスは同じ時間サーバーを実行するよりも多くのお金がかかります。
AJからの良い指摘ですね。それも本当です。AWSは公に認めたがらないけれど、私はコードと共にブログ記事を書き、彼らが予測的な自動スケーリングを行っていることを証明しました。私はそれを積極的な初期化と呼んでいます。それは本当にクールですね。コールドスタートの90%は事前にウォームアップされていましたが、あなたの経験は異なる可能性があります。
そうですね、コールドスタートさえも事前にウォームアップされている可能性があります。なぜなら、Amazonはそれらのことを検出しようとしているからです。とても興味深いですね。ここで何か極端なものはありますか、AJ？これは公平な指摘のセットだと思います。
ここで小さなことをします。成功的に避けている面白い潜在的な脱線を上に書きます。これらを避け続けることができるかどうか見てみましょう。1つ目は、Cloudflareがコールドスタートを避けるためにV8を使用する方法です。1つ目は、Verselのキャッシングです。1つ目は、データベースのためのHTTP接続方法です。
触れたい多くのことがありますが、話すべきことがもっとあります。サーバーレスマインドセットで構築している場合、これらのことを理解し、対処する必要があるということは、比較的合意されています。
サーバーレスマインドセットでの構築について話すと、AJは私たちをたくさん助けてくれました。もし私が何か言って、彼が同意しない場合、それがAWSやサーバーレスについてのことなら、私が間違っています。彼が正しいです。彼の言うことを聞いてください。素晴らしい内容です。
また、Twitchでこれらの異なるものをベンチマークする配信も行っています。もしこれが実際にどのように見えるのか興味があれば、AJをフォローするのは本当に楽しいです。私は絶対に彼のスレッド、コンテンツ、配信を使って、これらのことについていくようにしています。彼をフォローしていなかったなんて、私の方が情けないです。
とにかく、これらのことについて考えを巡らせたいと思います。なぜなら、私には本当にスパイシーな意見があり、それが実際にこの撮影の理由なのです。私のスパイシーな意見はこうです：サーバーレスな方法で構築するための要件は、より良いソフトウェアを書かせることになります。
そして、ここで私たちはスパイシーになれます。秘密の部分について、おそらく史上最大の関数型プログラミングの勝利としてサーバーレスを説得しようとしています。関数型プログラミングは、コードと関数のパイプラインを構築し、入力が与えられた時に常に同じ出力を生成するという概念です。
純粋関数、関数型プログラミングは世界で最も人気のあるものではありません。私は、誰もが全てを関数型で書いているふりをするつもりはありません。関数型プログラミングは、単に私たちが邪悪で、OOPを嫌っているから話題にするものではありません。それはアプリケーションロジックの理解を驚くほど単純にします。
これは、私が単体テストとテストの世界でうまく調和できる数少ない場所の1つだと思います。なぜなら、もし関数が純粋な方法で書かれていて、同じ入力が常に同じ出力を生成するなら、テストは本当に簡単です。デバッグも簡単で、理解も簡単です。
私が取り組んできた最も複雑なコードベースの一部は、このようなパターンを使用することで大幅に単純化されました。例えば、Twitchのコンテンツチームにいた時の動画インジェストのための狂気の並行パイプラインは、良いプリミティブを持つElixirで書かれていたため、Rustで書かれたWebSocketサーバーを読んで理解するよりも簡単でした。
もしあなたのコードが明確な入力と出力を持ち、それらの部分、関数が論理的な方法で構成できる場合、あなたのソフトウェアはより良く、より保守しやすくなるでしょう。
私にはこれについて話すいくつかのコンテンツがあります。私の最も好きなテック動画の1つ、これはオリジナルのBrian Willの動画なのでしょうか...「オブジェクト指向プログラミングは悪い」をチャンネルで見つけました。とても良い動画です。若い頃、私をコーディングYouTubeの世界に導いたものです。私はおそらくこの動画とBrianがいなければYouTuberにはなっていなかったでしょう。信じられないほどの内容です。
これは全ての開発者にとって必見の動画だと主張したいと思います。OOPが恐ろしいからではなく、私たちがそこに至った経緯と、なぜ他のプログラミング手法が良いのかという視点を得るためです。
先ほど言ったように、サーバーレスで構築することの面白い点の1つは、状態を分離する必要があるということです。状態を他の場所に持つ必要があり、サーバーレス関数を実行する時、例えばユーザープロファイルデータを取得するAPIがあるとします。
このAPIにアクセスすると、ヘッダーにあなたが誰であるかを知るためのクッキーがあり、プロファイルを提供するためにデータベースからデータを取得します。サーバーはリクエストから来るデータを含むことができず、データベースも含むことができません。なぜなら、それは他の場所で実行されているからです。
このコードを書き、このパイプラインがヒットされる時、2つの入力があります。最初の入力はリクエストで、2番目の入力はデータベース接続です。これら2つの部分を通じて、私たちは今...実際、技術的には、トップレベル関数の唯一の入力はリクエストです。
この関数はリクエストを取り、これがユーザープロファイルを取得するエンドポイントのためのものだと認識し、データベース接続を取得し、リクエストとデータベース接続を別の関数に渡します。その関数はリクエストをチェックして、このユーザーが誰であるかを把握します。
あなたを認証し、あなたが誰であるかを知った後、データベースを呼び出してユーザーのプロファイル情報を取得し、それをユーザーに送信します。その状態のどれもそのサーバー上に存在しません。1台のサーバーがそれを行っているか、100台のサーバーがそれを行っているか、100万台のサーバーがそれを行っているかは関係ありません。データベースが並行接続を処理できる限り、問題ありません。
しかし、もしその状態が至る所に分散されているか、ランダムなオブジェクトに付加されていて、サーバーを更新する必要があり、その接続に何が起こるか分からない場合、そのようなすべてのことは急速にカオス的になります。
ソフトウェアでデバッグしなければならなかった最も難しい問題のほとんどは、状態が間違った場所に置かれているという事実から来ています。
もう1つのホットな意見を投げかけましょう。これは、HTMX派の人々と私が同意する点でもあります。状態が存在する場所が少ないほど良く、理想的には、状態は必要のない場所には存在しないべきです。
ビジネスロジックやクライアントサイドのロジックのような、もしサーバーからすべての状態を移動し、クライアントがHTMLだけを取得する場合、サーバーとの間の送受信関係の理解は大幅に簡単になります。
もしサーバーサイドのロジックとエンドポイントからすべての状態を移動し、ロジックとコードの複雑さがそこにあり、状態は外部から引き出されるか、リクエストを通じて受け取るものである場合、いつ何が起こるかを理解することは大幅に簡単になります。
これはとても素晴らしく、関数型プログラミングのオタクとして、再びバックエンドのコードを構築することに興奮させてくれています。なぜなら、私が書いている実際のコードがとても単純で、以前考えなければならなかった他のすべてのこと、これはどのようにデプロイされるのか、デプロイスクリプトは何か、サーバーはいくつあるのか、サーバーのサイズは何か、仮想CPUはいくつあるのか、RAMはどれくらいあるのか、そのようなすべてのことについて考える必要がなくなったからです。
最近、いくつかのLaravel関連のものを立ち上げるために、これらのことについて再び心配し始めなければならなくなりました。物事が正しくプロビジョニングされていることを確認するための推測ゲームをプレイするのがどれほど面倒かを忘れていました。
これは楽しいことではありません。そして、これはあなたの頭の中で場所を取っているもう1つのことに過ぎません。この状態はどこに存在するのか、あるいはサーバーにはいくつのコアがあるのか、これはどれくらいのリクエストを処理できるのか、これらすべてのことは私の脳の中で時間を無駄にしてきたものです。
そして、これらのものを持つことができない場合、私が書いているコードと私が使用している脳の量が実際にはより単純であることに気付きます。これらのことについて理解するのがより簡単になります。
これらの要件が欠点ではないことに大変驚きました。これらは常に心配しなければならないものではありません。これらは私のコードをより良くするものです。
もちろん、これらのことができない時もあります。例えば、upload thingのインジェストサーバーのように、状態を持つ必要がある場合です。現在持っているチャンクのセットとそれらがどこに向かっているかを知る必要があり、それは一時的な状態ですが、サーバー上に存在する必要があります。
私たちはその一部をRedisに入れています。そうすれば、サーバーが即座に死んでも回復できます。しかし、それが接続を保持している性質上、サーバー上にあるべきです。そのため、そうしています。
しかし、このように構築できる場合、おそらくそうするべきだと言えるでしょう。なぜなら、これらのことについて理解することが劇的に簡単になるからです。
しかし、ここでさらに2つの追加の部分について触れる必要があります。私たちが話した最初の部分は、高速な起動時間の要件が理にかなっている理由と、それが実際には良いものである理由を説明するのに役立つと思います。なぜなら、それはロードバランシングからサーバーレスまで、すべてをより良くするからです。
ポイント2で、サーバーレスはアプリケーションコードのステートレス設計を必要とすると説明しましたが、それが理にかなっているだけでなく、実際には種類の良いものであり、あなたのコードを大幅に改善し、理解しやすくする可能性があることを説明しました。
しかし、次の2つ、ゼロへのスケールと、それは高すぎるコストについて話しましょう。ゼロへのスケールについて、これは私が少し考えを変えた点です。
これらの結論に至った経緯を、サーバーレスについて話さずに説明しましょう。2つの会社、PlanetScaleとTuroについて話しましょう。
これら2つの会社は外見上似ているかもしれません。どちらもフルスタック開発者がものを簡単にデプロイできるようにしようとしているサーバーレスデータベースプロバイダーです。しかし、いくつかの重要な違いがあります。
明らかに、PlanetScaleはMySQLとVitessです。大量のスループットに焦点を当てています。データの大量の量に対してはやや小さめですが、最も重要なことは、実行にサーバーが必要だということです。そのため、実行コストが高くなります。それでも私はPlanetScaleが大好きです。upload thingでもまだ使用しており、PlanetScaleなしでupload thingを構築することは想像できません。
Turoはかなり異なります。技術的にはSQLiteです。実際にはlibSQLです。なぜなら、SQLiteに変更をマージしてもらうのは不可能なため、SQLiteをフォークしたからです。しかし、正直に言うと、私はlibSQLが長期的には標準になると考えています。本当に良い状態にあり、採用も簡単です。
マルチテナントです。この場合のマルチテナントとは、異なる顧客のために異なるデータベースをスピンアップできるということを意味します。なぜなら、実際のところ、異なるユーザーのテーブルからデータを結合しようとすることはありますか？
例えば、upload thingで異なる場所や異なるリージョンにファイルをアップロードしている2人の顧客がいる場合、これら2つの異なる顧客を結合するクエリを実行する可能性はほぼゼロです。そして、異なる組織、異なる顧客、異なるアプリケーションを異なる完全なデータベースに分離できる場合、それらのデータベースの管理ははるかに簡単になります。
Turoは本当にそのようなことに焦点を当てています。一方、PlanetScaleはVitessを使用してシャーディングを行います。つまり、1つの巨大なデータベースを持ち、それをデータベース内の異なるキーに基づいて分割します。おそらく、それらに添付されているユーザーIDに基づいて、データベース内の異なるグループのデータをシャーディングしています。とてもクールですが、同様の問題に対する非常に異なるアプローチです。
しかし、両者ともサーバーレスフレンドリーなデータベースになろうとしています。Turoについてもう1つ詳しく説明すると、データはS3に保存されます。SQLiteをベースにしているため、デフォルトではSQLiteはただファイルに保存するだけです。TuroはそれらのファイルをただS3や任意のオブジェクトストアに保存します。
もしあなたのデータベースがあまりトラフィックを受けておらず、その後ユーザーがあなたのサービスにアクセスしてそのデータベースにアクセスする必要がある場合、先ほどサーバーレスで説明したように、彼らはS3からあなたのデータベースを引き出し、リクエストを解決し、しばらくの間より多くのリクエストが来るかどうかを確認し、来なければS3に戻すだけです。そして、リクエストが行われる時に再び取り出されます。
これは実行コストが信じられないほど安くなることを意味します。PlanetScaleは各データベースに対してサーバーまたは複数のサーバーを持っているため、ユーザー数に関係なく、それぞれにサーバーが必要で、それは高価です。そのため、PlanetScaleは最終的に無料枠を廃止せざるを得ませんでした。
一方、Turoは私が今まで見た中で最も寛大な無料枠の1つを提供しています。無料枠では500のデータベース、9GBの総ストレージ、10億行の読み取り、無制限の組み込みレプリカを提供します。無料枠としてはこれは信じられないほどです。
しかし、価格モデルを理解すると、より理にかなっていることが分かります。なぜなら、彼らの価格設定は、すべてのデータベースがサーバーを実行しているために大幅に多くの費用がかかることに基づいているのではなく、単にそのデータをS3に保存していることに基づいているからです。
これはまた、upload thingのような何百万、あるいは何千万ものファイルを持つものよりも生データの要件が低い小規模なプロジェクトに取り組む時、Turoが本当に良い選択である理由でもあります。そのため、pick thingにはTuroを使用しています。はい、実際に今Turoを本番環境にデプロイしていて、全体的にかなり良い経験をしています。
なぜこれらすべてについて話しているのでしょうか？これはPlanetScaleの価格ページです。PlanetScaleについて本当に好きな点の1つは、ブランチの概念です。ブランチは、データベースのスキーマのコピーで、データは含まれていません。単に同じスキーマです。
そのため、開発環境やステージング環境などで、データベースのスキーマを変更するために使用できます。新しい行の追加、新しいテーブルの追加、削除、新しいインデックスの作成など、何でもできます。それが確認され、人々が同意した後、GitHubのプルリクエストと同様に、デプロイリクエストと呼ばれるものを行って、これらのスキーマ変更を本番のスキーマに追加するよう要求できます。
しかし、これらの開発ブランチは実際のサーバーを実行する必要があります。なぜなら、PlanetScaleは実際のMySQL Vitessサーバーを実行しているからです。つまり、これらの各ブランチは、実際のデータベースとほぼ同じ費用がかかります。そのため、それらのブランチに基づいて請求する必要があります。
以前は固定数のブランチに対して支払いを行っていましたが、それはすぐに悲惨になりました。特に、ステージング環境の作成を自動化しようとした時、ブランチだけでも請求額がかなり高くなりました。そのため、彼らは使用時間に基づく請求に変更しました。
1ヶ月は30日、24時間として、720時間です。彼らが言うように、これが月の時間数です。そのため、メインティアで1ヶ月中2つのブランチを開いておくことができますが、3つ目のブランチが必要な場合、3人目の開発者が作業している場合は、お金を支払う必要があります。
もし古いブランチを寝かせるのを忘れたり、終わった時に削除するのを忘れたりすると、そのためにお金を支払わなければなりません。それはただ一銭一銭を絞り取ろうとしているわけではなく、実際にお金がかかるのです。
ここでPlanetScaleを悪者にしようとしているわけではありません。私たちが理由があってそれを使用しているサービスです。素晴らしいサービスであり、それぞれの価値があります。しかし、これらの種類の機能を実行するには多くの費用がかかります。
彼らがこの機能を構築した理由は、変更のデプロイプロセスを合理化し、GitHubやVercel、その他のエコシステムの素晴らしいツールで慣れているものにより似た感じにするためです。
Turoはまったく気にしません。ブランチについて言及しているのを見てみましょう。はい、ブランチについて言及していますね。ブランチ時間や数に関する概念はありません。なぜなら、再度言いますが、お金がかかりませんし、S3にSQLiteファイルを保存しているだけだからです。
PlanetScaleでは、複雑な計算をする必要がある一方で、ここでは単に「はい」と書いてあるのは面白いです。
ここで私の頭が変わり始めました。以前、特にPlanetScaleやSamと話している時、ゼロへのスケールについて強く主張する人々は、ユーザーがいないからそうしているのです。ユーザーがゼロの時のサービスがゼロの費用で済み、理論的にはいつか何千人ものユーザーを持つかもしれないサービスが、トラフィックが下がった時に合理的な金額で済むことを望んでいます。
私のような立場では...私のGaboがいくつあるか見たくもありませんが、192あります。192のプロジェクトを持っており、実際に定期的に削除しているので、それはかなりの数です。そしてもし、それらの異なるプロジェクトのほとんどが実際のトラフィックを受けておらず、それぞれに月5ドルのVPSを支払っているとすれば、それは安くない月額請求になります。
そして今、それぞれがプレビュー環境を持つ複数のプルリクエストがあることを想像してください。もし各プロジェクトが平均して5つのオープンなPRを持ち、それぞれにプレビュー環境があり、それぞれが月5ドルのサーバーを持っているとすれば（これは本番環境はおそらくより多くの費用がかかるため控えめです）、192 × 5プルリクエスト × 5ドルで、月額4,800ドルになります。これは私のGitHubリポジトリだけのためです。
そして、Turoをもっと使い始め、彼らのコストモデルについてより考えるようになり、ゼロへのスケールの魔法は本番環境でゼロユーザーを持つことには何の関係もないことに気付き始めました。ゼロへのスケールは本番環境には関係ありません。
これが私の頭を変えたことです。これはゼロユーザーの人々が良い時間を過ごせるようにする機能ではありません。はい、そうですが、それはクールです。ゼロへのスケールの利点は、開発環境、ステージング環境、その他のものがユーザーがいない時にお金がかからないことです。
もし月3,000ドルの巨大なサーバーを実行して信じられないほどのトラフィックを処理している場合、開発で作業している時、より小さなサーバーで実行するか（つまり、実際の本番環境を複製していない）、または開発者環境のインスタンスごとにコストが2倍になります。
私は企業がそれを実行可能にするために狂ったことをしているのを見てきました。ここでは、あまり話さないと言った会社について示します。これは私の個人のVercelアカウントです。ホビーティアであることに注目してください。私の個人のVercelアカウントでは支払いをしていません。なぜなら、必要ないからです。十分なトラフィックを得ているものはビジネスアカウントにあります。
しかし、ここで私が気にするのは、持っているアプリの数とはほとんど関係ありません。ちなみに、多くのアプリをデプロイしています。show moreボタンを押してみましょう。もう一度show moreを押してみましょう。そうです、無料枠で多くのアプリをデプロイしていて、それは問題ありません。
しかし、さらに面白いのは、ブランチがあるものに行くと、これは良い例になるでしょう。T3 Astroに行きましょう。デプロイメントに行くと、これらはすべて2年以上前に行った異なるプルリクエストのためのデプロイメントです。
本当の魔法の準備はできていますか？2年前のデプロイのリンクをクリックしたところ、ほぼ即座に正常に動作しました。これはユーザーがゼロかもしれません。客観的にユーザーはゼロでした。2年前のアプリケーションのプレビュービルドを誰も確認していません。
このタイプのワークフローは、サーバーレス環境でのみ実行可能です。そして、これがゼロへのスケールが実際に提供する秘密の勝利です。もしサービスがゼロユーザーを持つコストがゼロに近ければ、そうでなければ決してできないことができるようになります。
私たちはPlanetScaleのブランチモデルを見ました。それはクールで、動作していますが、ブランチをスピンアップするのに時間がかかり、手動でスリープさせない限りお金がかかり、それでもお金がかかります。一方、Turoのような何かを使うと、より多くのデータベースをスピンアップするだけで、誰も気にしません。
新しいデータベースをスピンアップするのは、ボタンをクリックするだけで、即座にそこにあります。なぜなら、それは単に新しいSQLiteファイルを作成するだけだからです。これらのことについて心配する必要がなく、それによってワークフロー、アイデア、そして他の方法では不可能なことが可能になります。
サーバーレスのような何かがなければ、このように良いプレビュー環境の経験を持つことはできません。なぜなら、このコードを実行し続けることはできないからです。私の個人サイトの無料枠Vercelアカウントで、これらの数百のプレビューを準備し、すぐに利用できる状態にすることはできません。
これらのリンクのどれかをクリックすると、ページがすぐに解決されます。これは私の古いバージョンのウェブサイトです。これはとても素晴らしいです。最近まで、Vercelはこれらのデプロイメントをすべて無期限に利用可能な状態を保っていました。今では60日で自動的に削除するオプションがありますが、私は気にしません。
なぜ気にする必要があるでしょうか？それはS3に何年も置かれているコードから適切なコードを取得しているだけです。コードは大きくありません。数メガバイトのものです。それらをLambdaに取り込み、即座にスピンアップでき、実質的に費用はかかりません。
そのため、障害が発生し、いつ問題が発生したのかを特定しようとしている場合、単にスクロールするか、フィルターで本番環境を選択できます。これが私の個人サイトで行った本番デプロイメントのすべてです。1年以上行っていません。明らかにもっとブログ記事を書く必要があります。
そして、これらは利用可能です。そのため、バグがあり、いつ壊れたのか気になる場合は、クリックしてみてください。ここでは動作しますか？はい、ここでは動作します。古いものだったに違いありません。
これはサーバーを使用しては不可能です。大規模にオーバープロビジョニングし、コードの動的なロードとアンロードのための独自のワークフローを構築し、そこで必要な遅延に対処しない限り。Fly.ioのようなもので、このようなものを構築している人を見たことがありますが、リンクをクリックしてからサーバーがスピンアップして実際にコンテンツを表示するまでに最低でも5〜10秒かかります。これは緊急時には最悪です。
また、古いバージョンに切り替えたい場合はここでの方法はとても簡単です。クリックするだけです。申し訳ありませんが、ホビー顧客はインスタントロールバックができませんが、有料アカウントであれば1回クリックするだけで全トラフィックが古いバージョンに移動します。
しかし、トラフィックがリダイレクトされているわけではありません。実際に起こっているのは、ユーザーが現れた時に、単に異なるコードを解決するということです。これは魔法のようです。
このようなワークフローは、ゼロにスケールできるためにのみ可能です。なぜなら、ゼロにスケールできなければ、これらは終了しなければならないからです。これらすべての古い本番環境、私が今まで持っていたすべての古い本番デプロイメントは、現在ゼロにスケールすることの恩恵を受けています。もしゼロにスケールできなければ、それらは終了しなければならず、そこにとどまることはできないからです。
これは完全に真実です。ゼロにスケールは、あなたの製品が季節性を持っているか、1日の中でも少し活動的で、その後は活動的でない場合に有用です。しかし、他の自動化されたサービスと対話している本番サービスの場合、ゼロにスケールはある意味で無意味です。
Lambdaのプロビジョニングモードを使用してお金を節約できますが、それでもFargateと比べても高価です。そうですね、そして正直に言うと、開発者の世界ですべてがサーバーレスで行われるような方法で物事を構築し、コードを書いて作業している時はそれを使用し、その後、実際のデプロイされたバージョンのコストの垂直統合を最適化したい場合は、本番バージョンをFargateにするのは完全に問題ありません。
それは全く問題のない、受け入れられる方法だと思います。なぜなら、繰り返しになりますが、サーバーレスでステートレスなコードは、サーバー上でも問題なく実行できるからです。サーバーフルなランタイムを期待するコードは、デバッグがより困難で、サーバーレス環境に投げ込んでそのまま動作することは期待できません。
Coolifyが好きです。最近、Coolifyの開発者ともっと話をしています。しかし、はっきりさせたいのは、Coolifyはこれらの多くのことを合理化するのに役立ちますし、これらのワークフローをサーバーで複製する数少ない方法の1つですが、サーバーレスなしでこれを持っている人はいません。
ワンクリックでスワップオーバーできる、アプリケーションの今までにデプロイされたすべてのインスタンスを持つことはできません。それは他の方法では起こりません。
おそらくCoolifyについて知らない人のために説明すべきでしょう。Coolifyはセルフホスティングのスーパーパワーです。彼らのクラウドを使用するために支払うか、すべてがオープンソースなのでセルフホストします。そしてCoolifyをデプロイします。
実際に、私のCoolifyダッシュボードを見つけることができるか見てみましょう。ただ、私が実際にCoolifyを使用している証拠として。ダークモードにしましょう。皆さんにあまり怒られないように。
GitHubプロジェクトを接続し、設定し、既存のサーバー上で多くのDockerイメージを実行できます。つまり、Coolifyは専用のVPS上で実行され、その後、異なるものに対して小さなDockerイメージをスピンアップします。
ここには私のLaravelデプロイメントとPostgresがあります。これらは互いに通信する別々のDockerイメージです。そのため、ここでステートレスなワークフローをある程度複製することができます。
しかし、これらはまだプロビジョニングされる必要があります。ありがたいことに、PHPではコードを基本的にホットスワップできます。気にしません。そのため、PHPでは少し近づけることができますが、他の言語には起動時間と期待があり、それらをホットスワップすることはできません。
Coolifyがどれほど素晴らしいか、そして信じてください、かなり素晴らしいのですが、ワンクリックで再デプロイし、即座に再デプロイし、GitHubの各PRがプレビュー環境リンクを持ち、それが永久に存在するという力には及びません。
だから、古いPRを見て、それがどのように動作するか見たい場合、リンクをクリックすれば動作します。他の誰もこれらのことをこのように行っていません。他の方法、と言うべきでしょう。サーバーでこれを行うことは、多額のお金を使わない限り、本当に不可能です。
そして、Yashがチャットで言ったように、QAと開発環境で年間10万ドルの請求を積み上げている会社を知っています。私は個人的にAmazonとTwitchでそれ以上の金額を積み上げたことがあります。それは難しいことではありません。
AJは、3から4に移行するための素晴らしい移行ポイントを私に提供してくれました。ここで、ゼロにスケールの利点は、ゼロユーザーの場合に物事がクールであることではなく、無限の数のデプロイメントを持つことができ、それについて考える必要がないということを適切に確立できたと願っています。
なぜなら、誰が気にするでしょうか？それはただS3に置かれているデータで、リクエストが行われた時にロードされるだけです。このように構築し始めると、そうでなければ持てない超能力を手に入れることができ、それは魔法のようです。
これは、私のお気に入りの関数ベースのもの、Reactと似ています。「あ、そのコンポーネントを再利用できる」という魔法は、「ああ、これは根本的にソフトウェアの構築方法を変える」というようなものです。
そして、これを行っていた時、私もそのように感じました。ただ、ゼロにスケールがこれらのことが機能し、とても素晴らしい理由だと気付いていませんでした。直感的には知っていましたし、聞かれれば理解できたでしょうが、Turoを使用することで私にはっきりと分かりました。
Turoがブランチング、データベースの数などについてこれほど寛大になれる理由は、データベースがS3に保存され、単にS3から読み書きするためのsqliteを実行するサーバーがあるからです。これはとても素晴らしく、基本的にLambdaやVercel、Netlify、そしておそらくCloudflareがどのように機能するかと全く同じモデルです。
そして、Cloudflare V8の話題に触れないようにするのは本当に難しいです。コメントで、この話を聞きたいと教えてください。そうすれば、この動画を撮影する正当性を得られます。人々が気にしないと思うのですが、あなたが私を説得できれば、これを撮影するのはとても楽しいでしょう。
しかし、今は最後のポイントについて話す必要があります。サーバーレスは、同じ時間サーバーを実行するよりも多くのお金がかかります。
5ドルのVPSを実行するコストと、得られる計算能力を比較した場合、「ああ、それは月5ドルで、これらすべての計算能力が得られる」というように見えます。一方、サーバーレスでは、もはや持っているサーバーの数に基づいて請求されません。
ギガバイト時間は、使用されているRAMのギガバイト数を測定する単位です。ギガバイト時間を説明するのは本当に難しいです。AJ、GBHを一般の人に分かりやすく説明するにはどうすればいいでしょうか？それは愚かな指標だからです。
ガブリエル、それは秒単位のギガバイトですが、時間単位です。くそっ。長い間、質問にこれほど傷つけられたことはありませんでした。これは追加の話題を生むかもしれません。もう1つの話題が思い浮かびました。これは実際に記録しながら行うかもしれません。
抽象化のティア：ベアメタル、EC2、ECS、Lambda。それは面倒な話になるでしょう。彼はおそらくブログを書いています。また、彼の仕事をし、人生を楽しんでいるのでしょう。
これは基本的に私が説明しようとしていた方法です。1GBを割り当てられた関数が1秒間実行される場合、1ギガバイト秒を消費したと見なされます。つまり、1ギガバイトのRAMを持つLambdaがあり、1秒間実行された場合、1ギガバイト秒を実行したことになります。
これは面倒です。なぜなら、CPUの数やその他の要素が存在し、それらは追加のコストベクトルですが、ギガバイト秒のメトリックは、ほとんどのサーバーレス請求の測定方法です。
例えば、Lambda上で4GBのRAMを使用するようにサービスを設定し、1時間あたり100リクエストを受け、各リクエストが1秒かかる場合、毎時400ギガバイト秒を使用することになります。リクエストあたりの秒数に、リクエスト数とギガバイト数を掛けて、これらの数字をすべて組み合わせると、それが使用量となります。
これを増やしてみましょう。1時間あたり1000リクエストとし、1リクエストあたり1秒の時間を維持します。これは1時間あたり4,000ギガバイト秒に相当します。明確にするために、GBTimes sと言うべきです。チャットの訂正ありがとうございます。そして、それは月あたり2,880,000GBSになります。
ここで価格を見てみましょう。他のすべてをスキップして、4ギガを見てみましょう。なぜ1ミリ秒あたりの価格を表示しているのでしょうか？それはとても面倒です。ここに4ギガのRAMがあります。これを1000倍して、実際の秒数を得ましょう。これがギガバイト秒あたりのコストです。
ここに戻ると、4GBサーバーのGBSコストはその小さな数字に等しくなります。そこで2,880,000を取り、この数字を掛けると、月額192ドルになります。総コストは192ドルです。
そしてそれを考えると、特に同等のVPSやEC2の価格と比較すると、痛いですね。EC2の価格を見てみましょう。時間あたりのレートを表示するのをやめてほしいです。T4G mediumを取り、60倍して、24倍して...それは正しくないかもしれません。それは時間あたりですよね？
同等の4ギガRAMサーバーを1ヶ月中実行する場合、月額24ドルになります。その代わりに単にサーバーを実行した場合、滑稽なほど安くなったでしょう。明らかに5ドル/月のVPSではありませんが、25ドル/月で単にこのサーバーを実行し、その法外な金額を支払う必要はありません。
しかし、ここにはいくつかの注意点があり、それらについて触れたいと思います。1つ目は、ここで1時間あたり1000リクエストです。このような一定のリクエストレベルを持つサービスは非常に少ないです。
もしあるとすれば、クーロンジョブやキューからプルするインジェストのようなものです。実際には、ほとんどのサービスのトラフィックはこのようになります。トラフィック量が常に上下し、そのピークがあなたにとってどれほど重いかによって、そのピークを処理するのに十分なサーバーをスピンアップするコストは、かなり高くなる可能性があります。
重要なコストは、トラフィックが正確に固定されている場合に、サーバーとサーバーレスのどちらが安いかということではありません。問題は、トラフィックの低点と高点の間のギャップがどれくらい大きいかということです。
このポイント間のスペースは、サーバーレスの魔法です。特定の時点でトラフィックがどれほど高いか、あるいは低いかを気にする必要はありません。コストはそれに応じてスケールされます。もし特定のユーザーのリクエストがかかるコストを合理的な金額で価格設定できれば、脳を切ることができます。なぜなら、この方法で構築していない場合の厳しい現実は...ここでは月額24ドルの4ギガバイトサーバーがあるとします。
もしここにいて、これがピークであれば、月額24ドルを支払っています。その瞬間そこを超えると、コストは2倍になります。ここからここまでのギャップで、コストが2倍になることは最悪です。もしこれらのことを気にかけ、自動スケーリングが遅すぎて、サーバーが十分早く応答できないか新しいサーバーをスピンアップできないためにユーザーがページのタイムアウトを経験した結果としてトラフィックを失う場合、そのコストは悪化する可能性があります。
顧客を失うコストと、過剰なプロビジョニングのコストの両方です。では、この内訳に戻って、1時間あたり1000リクエストを見てみましょう。それぞれ1秒かかると仮定します。ああ、私の計算がかなり間違っていたことが分かりました。なぜ誰も訂正してくれなかったのでしょうか。ギガバイト秒は720,000になります。
そのコストがどれほど大きかったかについて今、失礼なコメントを書いている場合、計算を二重チェックすることを願います。そうしないと、本当に愚かに見えるでしょう。突然、これはより合理的に見え始めます。なぜなら、ここでの実際のコストは48ドルになるからです。
先ほど見たVPSを覚えていますか？追跡を失いましたが、皆さんはアイデアを理解したと思います。4ギガバイトサーバーで月額約24ドルでした。このトラフィックをすべてLambdaで処理すると、価格は2倍になります。それは恐ろしく恐ろしいことでしょうか？
しかし、再び私のグラフに戻ると、この閾値を超えた瞬間、新しいサーバーがスピンアップするのを待つ必要があるか、あるいは代わりに2台のサーバーの費用を支払うことを決定しなければなりません。
しかし、これらの数字の分布方法で遊んでみましょう。なぜなら、1時間あたり1000リクエストを設定しました。これは月に720,000リクエストです。1日を通じて均等に分散していると言えますが、少し変えてみましょう。
理論的な代替案として、1日あたり500リクエストだけ受け取るとしましょう。計算してみましょう。29日間で500リクエスト、それは29日間で14,500リクエストです。しかし、その後1日、あるいは1時間に大きなスパイクが発生します。このギャップのスパイクとしましょう。
720,000から14,500を引いたので、このスパイク...さらに低くしましょう。600,000リクエストとします。1時間に1日だけ、この大規模なスパイクで600,000リクエストが発生します。普段は1日500リクエストを受け取っています。
ああ、私の現在の計算は正しかったでしょうか？4ギガバイトを使用したので...私がたった今行った計算を見てください。そうですね、4倍を忘れていました。これらのことを生放送で行う前に、もっと計画を立てるべきでした。再び訂正します。4ギガバイトだったのでその数字になりますが、現実的であるために何かを変更します。
今からRAMを1ギガバイトにします。なぜなら、現実的に言えば、4ギガバイトのRAMですべてのリクエストを処理するサーバーは、1ギガバイトのRAMで個々のリクエストを処理するサーバーと同等だからです。それらのリクエストに1ギガバイトのRAMを持つのは、おそらく過剰なプロビジョニングです。
そのため、これを戻しています。1ギガバイトのRAMを想定しています。これは若干性能の低いサーバーですが、各ユーザーのリクエストが4ギガバイトのRAMを使用している場合、いずれにせよ同時リクエストを処理することはできません。クール、私の計算は正しかったですが、はい、とにかく。
1ギガバイトのRAMで、通常は1日500リクエストですが、その1時間に600,000にスパイクする場合、それを処理するのは大変です。そして、ここで物事が面白くなり始めます。
サーバーでこれを構築していて、そのような大規模なスパイクを処理する準備が必要な場合、オプションは非常に限られています。通常のトラフィックがここにあり、ほとんどの日はこの範囲で推移していますが、ほんの一瞬それをする場合、それをプロビジョニングするのがどれほど悲惨か知っていますか？
なぜなら、あなたのロードバランサーコードが信じられないほど優れていたとしても、スパイクが激しすぎる場合、それをロードバランスすることはできないからです。そのため、今やあなたのオプションは、この潜在的なスパイクに基づいてプロビジョニングすることです。
つまり、サーバーをはるかに重くプロビジョニングしていますが、もしウイルス的に広がり、サーバーがそれを処理するように設定されていなかった場合、最初のユーザーの相当数がデッドページにヒットすることになります。なぜなら、それは解決できないからです。
そのスパイクを処理するために、それが解決できるようにするために、サーバーを600倍以上オーバースペックする必要があります。そして、それが問題です。トラフィックの分布方法が、これらのコストがあなたにとってどのように機能するかを根本的に変えるのです。
もちろん、ロードバランサーはそれを処理できます。AWSがどのように行っていると思いますか？ロードバランサーが新しいサーバーを作成すると思いますか？Amazonはサーバーを使い果たした時に？
Amazonは史上最も過剰にプロビジョニングされた企業であることでこの問題を解決しています。Amazonのサーバーは既にそこにあります。彼らは既に購入し、それらは待機しています。そのため、はい、Amazonのように多くのコストを消費したい場合は、あなたも大規模に過剰プロビジョニングすることができます。
しかし、Amazonのクールな点の1つは、非常に多くの人々が非常に多くのサーバーを購入しているため、効果的にバランスが取れているということです。なぜなら、私のサービスが大規模なスパイクを経験している場合、他の多くのサービスはそうではないからです。
そのため、彼らはより多くのサーバーを購入することを正当化できます。なぜなら、彼らは誰もののスパイクを処理できるからです。それは彼らのモデルに組み込まれています。しかし、もしあなたがAmazonでないなら、それらの単一のスパイクのために大規模な過剰プロビジョニングされたサーバーセットを実行するべきではありません。それは単に意味がありません。
理論的なランダムなウイルス的イベントについて心配することは狂っているように見えます。大規模な広告スパイクの後のレベルのトラフィックを見てください。私が今まで取り組んできたものすべてに、ランダムな5倍以上のスパイクがありました。文字通り、私が今まで取り組んできたすべてのものです。
それがupload thingであれ、誰かがランダムに全てのファイルを移動することを決定し、1時間に100万個のファイルを移動する場合であれ、Twitchチャットであれ、Drakeがninjaのストリームに現れ、私たちが1秒あたり50万メッセージから1500万メッセージに移行する場合であれ、それは単なる実際の本番ワークフローです。
私はこう言いたいと思います。もしあなたの立場が「まあ、誰もがウイルス的に広がるわけではない」というものなら、あなたは実際の本番ワークフローで作業していないということです。これは期待されることです。それは視聴者数でしたが、1人の視聴者が大量のメッセージを送信することができます。
そうですね、レベルには彼のサーバーのロードバランシングを管理する専任の人がいます。そして人々が指摘しているように、彼も大規模に過剰プロビジョニングしています。
もしあなたのトラフィックが乗数的な変化を持つことができ、ある期間で5倍高くなる可能性があり、低トラフィックから高トラフィックへの変化の速度が速い場合...これらは私が言葉の表現を見つけようとしていたことで、それが私に浮かび始めています。
サーバーレスをより安価で良いオプションにする特定の特徴があります。大きな2つは、トラフィックの高低の間のギャップと、高低トラフィック間の変化の速度です。なぜなら、このトラフィックスパイクがここにあり、それが直線的に上がる代わりに、徐々に増加する場合、ああ、ロードバランサーはそれを問題なく処理できます。
「一般的に高分散」と言っていますが、その言い方が好きです。もしトラフィックの上下の分散が高く、その上下の速度も高い場合、サーバーレスは非常に理にかなっています。
そして、AmazonがLambdaとサーバーレスをこれほど重要に使用する理由があります。トラフィックがこれらのランダムな方法でスパイクする可能性がある場合、それは正しいプリミティブです。それは非常に強力です。
そして、「Amazonがどのようにしているのかどうやって知っているのか」と言う人々が理解に失敗していることは、Amazonのサービスは大部分が彼らが内部で必要としたものに基づいて構築されているということです。
この非常に長い動画の冒頭で説明したように、彼らは非常に論理的な道筋でサーバーレスに辿り着きました。私たちは古い方法からここに移行し、アプリケーションコードを独立してスケールできるようにデータベースを分離し、アプリケーションコードをアプリケーションボックスから移動できることに気付きました。
しかし、ここに戻ると、1時間に600,000リクエストがどれだけのリソースを必要とするかについて理論的な例を作るのは難しいので、実際の数字を使用してみましょう。
Basecampは1秒あたり5,250リクエスト、最大負荷時に500コアを使用しました。それぞれがAMD Z5 192コアチップを実行する3つのボックスです。はい、しかし私が経験した最高の栄誉の1つは、Ryanの頭の中で何かがクリックするのを助けたことです。彼のように本当に何でも知っている人に、たまたま理解していないことを理解させることができるのは魔法のようです。なぜなら、彼らはそれを行っていないからです。
はい、Ryanが多くのことを知っている大きな理由は、彼が学ぶ時間を取り、より良く知っている人々と話をし、学び、間違いを認める意志があるからです。しかし、はい、彼は何でも知っているように見えます。
とにかく、テクノロジーの中の別の賢いもの、Kubernetesの説明に戻りましょう。Kubernetesについて触れ、その言葉を書き出すことで、皆さんに少しトラウマを与えたことを願っています。
私のブランドとチャンネルで推進しようとしている特定のことの1つは、大企業の特定のタイプのワークロードにとって機能するこれらのものを取り上げ、平均的な開発者がそれらに触れるべきでないことを確実に知ってもらうことです。
100%のコードカバレッジやKubernetesのようなものは、特定の大企業では理にかなっているかもしれませんが、中小規模の企業や、大企業の中小規模のチームの大多数にとっては、はるかに意味が少なくなります。
誰がこのことに気付いたと思いますか？AWSです。ここまでの文脈を整理しましょう。最初は1つのボックスにすべてがありました。次に、データを失うことなくこれを交換できるように、アプリケーションコードとデータベースレイヤーを分離しました。そして、これらの複数を同じデータベースに接続して実行でき、どれでも問題ないことに気付きました。これはスケーリングがはるかに容易になり、Nodeを実効的なものにしました。ここで指摘しておくべきなのは、Nodeの同時実行モデルはI/O束縛のタスクには優れているものの、重い処理には向いていないということです。そのため、複数のサーバーをスピンアップできる機能は、特にNodeにとって非常に有用でした。
しかし、ここでAWSで明らかになり始めたことがあります。なぜ私たちは、実行するサーバーの数について考える必要があるのでしょうか？そしてなぜそれらすべてを常時実行する必要があるのでしょうか？
理論的なシナリオを設定してみましょう。
数字で見てみると、Hetznerの価格ページでAMDを選びます。48コアモデルしかできません。48コア、96スレッドです。彼は何コア必要と言っていましたか？最大負荷時に500コアです。彼のために丸めてみましょう。10のこれらが必要だとしましょう。12回掛けると、年間28,000ユーロになります。そこまで良くありません。
2,360ユーロですが、USDに換算しましょう。1つに262ドル、そのため彼のトラフィック用に十分な数があれば2,620ドルです。5,250リクエスト/秒とのことでした。
彼は500コアと言いました。それは最大トラフィック時のためです。もし8時間の勤務日でピークトラフィックが中間にあるとすれば、おそらく1日のほとんどの秒では10分の1程度だと考えるのが妥当でしょう。おそらくさらに低いでしょう。
その仮定で作業しましょう。平均すると10分の1以下で、最大で5,250であり、これを2,625にまで平均化しましょう。これは寛大な数字です。実際にははるかに低く、週末はほとんどないでしょう。
これに60を掛けて分、時間、日数を求め、それが月のリクエスト数だとしましょう。さて、サーバーレス側でこれらの数字を盲目的に仮定してみましょう。明らかに不公平です。ここには他にも多くの要素があるかもしれません。
もしこれが単にデータベースから値を取得してHTMLをレンダリングするだけなら、1ギガバイトのRAMはほぼ確実に必要ありません。リクエスト数をここから取得しましょう。また、リクエストあたり1秒というのは異常です。リクエストあたり0.5秒としましょう。
月に2億8300万リクエストです。そして再度明確にしておきたいのですが、これはナプキン計算です。7000万ギガバイト秒になります。quick mathをやってみましょう。7100万に丸めます。
見てください。両側に比較的寛大な仮定を置いてみましたが、私はかなり公平だと考えています。同じサービスをサーバーレスで実行すると、半分のコストで済みます。なぜなら、それらのサーバーは週末に誰も使用していない時も費用がかかることを忘れないでください。
ロードバランシングを設定することはできますが、自分のハードウェアを購入しているため、それはできません。それは価格の半分以下です。そして、これには多くの穴を指摘できることを確信しています。人々がそうするのは分かっています。既にそれがスクリーンショットされてTwitterに投稿されることが分かっています。
明確にしておきましょう。もしそのレベルの持続的なトラフィックがあるか、平均的な日でもそのトラフィックレベルの半分程度まで下がるだけなら、絶対にサーバーをスピンアップしてください。しかし、ピークトラフィックが週末のトラフィックよりもはるかに高い場合、このようなシステムを使用することは驚くほど安価です。
そして、プロビジョニングコストのパフォーマンスバランスを理解するために、すべての時間を費やしたくない場合、この方法での構築が彼らにとってより簡単であれば、その方法を選ぶべきです。なぜなら、1000ドル/月のギャップは年間12,000ドルです。
もし私のエンジニアを意味のある量の努力から救い、年間12,000ドルを支払うことで彼らをより幸せにできるなら、それは考える必要のないことです。会社全体の費用としてはそれほど大きくありません。これらの数字は両方とも、会社が持つエンジニアに関連して本当に小さいものです。それが現実です。
そして、このような方法で構築することの利点を、ほとんどの人が理解し始めることを願っています。それはアプリケーションをより回復力のあるものにし、デプロイメントとロールバック、プレビュー環境などを行うのがより簡単になります。
DHHの方法でやるよりも、サーバーレスな方法で行う開発者体験の方が悪いと私を説得するのは本当に難しいでしょう。そして、実際のアプリケーションワークフローの大多数、つまりユーザーであれ外部APIであれ、外部ソースに直面しているものは、本当に複雑なロードバランシングを設定するか、大規模に過剰プロビジョニングする必要があるほど、トラフィックの変動が十分にあります。
これが過剰プロビジョニングの姿です。そして再度言いますが、開発者の数に関連して、それはまだかなり安価です。Twitchで複雑な動画インジェストを行っていた時、これが私たちが選んだ道でした。ビデオインジェストをサーバーレスで行うのは文字通り意味がありません。しかし、私たちは月額2,600ドルよりもはるかに高額なサーバーをスピンアップしていて、それについて二度と考えませんでした。なぜなら、それはまだそれに取り組むエンジニアよりもはるかに安価で、彼らの時間を節約できたからです。
この動画でいくつかの悪い計算をしました。ポストでどのように対処するか分かりません。23,500,000リクエスト/月は妥当だと合意しました。これは私が犯した間違いです。はい、60 * 60 * 30にしましたが、60 * 24 * 30にすべきでした。60 * 24で割った実際のリクエスト数は半分でもありません。
計算をやり直して、そうですね、私はすでにDHH側に寛大でしたが、私の側で大きな誤りをしました。2,835...472ドルですが、サーバーレスはとても高価ですね。ああ神様、この時点で私はただイライラしています。
この非常に長い話を締めくくるために、私の動画を参照します。チャンネルに行って動画をヒットし、人気順にすると、これです。「AWSの実際のコストとその回避方法」です。50万回再生に達しそうで、これは私の最も人気のある動画になるでしょう。
AWSの実際のコストは、今日私たちが話してきたこれらすべてのことではありません。それは、あなたが構築に費やしている時間の量です。もしLambdaやVercel、Netlify、Cloudflare、upload thing、PlanetScale、Turo、またはこれらのものを使用でき、開発者に意味のある量の時間を節約できるなら、それはおそらくそのコストよりも安価です。
私たちがここでこれらのギャップについて議論するのは楽しいことですが、これらは給与と比較になりません。もしここのソリューションが2人の追加のエンジニアを必要とするなら、価値がありません。もしこのソリューションが1人の追加のエンジニアを必要とするなら、それも価値がありません。
合理的になりましょう。しかし、これらの決定をどのように行うかについて、これらの数字についてそれほど考えるのをやめましょう。なぜなら、ギャップはそれほど大きくないからです。サーバーレスは高すぎるだけでなく、現実的なトラフィックとスケールでは代替案よりも多くの場合安価です。
そして、ゼロへのスケールは、はるかに優れた開発環境と体験をもたらし、サーバーでは不可能なことを可能にします。はい、それだけです。
このような長い動画には本当のアウトロをするべきでしょうが、気にしません。コメントで私が間違っている理由を教えてください。また会いましょう。peace。

いいなと思ったら応援しよう！