[イベント駆動型アーキテクチャ] はじめに
先月末に "Japan Dreamin' 2023" で発表した "イベント駆動型アーキテクチャにするんだ" を何回かに分けてお話ししていきます。わたしの技量的に、いっぺんに全てを公開していくのは厳しいと考えたので、適度に分割して順次公開します。
はじめに
イベント駆動型アーキテクチャの話をする前に、ちょっと事前の前振りをします。
まず、思い浮かべていただきたいことがあります。あの、たまにアクセスできなくなる、あのサイトです。たとえば、TV CM や LINE で広範に広告されたケース。予約の開始時刻がきまっている。これらのサイトでよく起こりえますよね。静的なコンテンツサイトであれば、CDN などを活用して分散することである程度の対応ができます。ただ、予約などの動的なサイトは、厳しめにアクセス制限していることが多いでしょう。私もそのアクセス制御にはじかれる一人です。
指定された時刻にアクセスして、特定の公演を押すとはじかれるあの寂しさ。何度もF5しながらアクセスできたけれども、既に埋まっている何か。いろいろ思い当たる節が、みなさまにもあるんじゃないでしょうか。
逆に、どんなときでも、いつでもどこでも受け入れてくれるようなショップサイト。バーゲンやっていて、恐ろしいアクセスが来ているにも関わらず、何故か捌き切れているあのサイト。そんなサイトもみなさんご存じではないでしょうか。
この二つのサイトの違いはなんでしょうか。
これらｈ、一般的なWebシステムに介在する根本的な課題があります。Webシステムは、一般的にフロントにアクセスを受け付ける "Webサーバ" がいて、そのバックエンドに "DBサーバ" がいます。"Webサーバ"と"アプリサーバ" を分けているような、Web 三層構造の懐かしい構成もあるでしょう。一旦そこは Webサーバでアプリが実行されると想定して、Web と DB だけで考えましょう。
このようなWebアプリケーションシステムでは、この "DBサーバ" がボトルネックになります。一般的に"DBサーバ"には、スケールにしにくい "RDBMS" (Relational Database Management System) が利用されます。使いやすいので。
大量の Web へのアクセスをさばくにしても、まず "Webサーバ" を増やしておけば、ある程度は分散して同時アクセス数を伸ばせるでしょう。しかし、"DBサーバ" は、なかなかスケールはできません(最近はあるけどね)。そのため、どうしてもデータをコミットする処理だとか、同時に適切な処理をするには、ある程度の制限をかけながら利用せざるを得ないという事実があります。
実は、これはアクセスを捌こうとするための資金力があれば、ある程度、制御可能です。お金をかければ "Webサーバ" も増やせるし、"DBサーバ" もハイスペックなものを準備できます。でも実はそれだけではなかったりします。いずれ、DB やアーキテクチャの限界によって、アクセス制御しなければならないことがやってきます。
そこで、より余裕のあるサイトではどのようなことをしているかというと、同時に処理をしなくても良いことを後回しにしてしまいます。
例えば、メールの送信が完了しなくても良いよねとか、クレカの決済が終わるのを待たなくても良いよねとか、やたらめったら時間のかかる処理があるけど、それが終わるまで待たなくて次の処理しても良いよね。とか。
いわゆるこういった、全ての処理が完全に終わるまで、次の処理に移らず、ユーザにも結果を返却しない処理のことを "同期処理" と言います。
特定の処理を後回しにして、システムに負荷のかかっていないときや、別のタイミングに分散するような処理の仕組みを "非同期処理" と言います。
このように、システムの過負荷を軽減して抑制し、多くのユーザに利用してもらえるようにしたり、ユーザにとってのユーザ体験を向上させるような仕組みは、 "非同期処理" で実現できる部分があると言うことです。
良い例なのでサイト名を出しても問題ないと思いますが、例えば、ヨドバシカメラ や Amazon といったショッピングサイトでは、クレカの決済は購入時に行われていません。ヨドバシカメラ で購入した後、ヨドバシから「クレジットカードの決済のご利用確認が完了いたしました」というメール来たことありませんか？ Amazon も実際の商品発送時に決済がなされているようです。Amazon にいたっては、ものによっては在庫の引き当てもされていなくて、後で「ごめーん在庫なかったー」なんてケースもありました(今は知らない)。
このように、大量のユーザアクセスが想定され、多くの処理をしたい、またはユーザ体験を向上させたいというサイトでは、こういった非同期処理も利用されています。
Salesforce でも、この非同期処理は利用可能です。 たとえば"Apex" で実現可能です。"非同期Apex" を利用することでシステムの負荷を軽減し、使えるヒープ領域を増やしたり、Apex 同時実行数を緩和させて、ガバナ制限に引っかかりにくくできるというメリットもあります。実行時間も延長できたりもするので、ガバナやばいというケースには "非同期Apex" の利用もご検討ください。
イベント駆動型アーキテクチャでは、この "非同期処理" を活用して、疎結合化や処理の分散処理を行うような仕組みを実現します。
今日はここまでです。
次回は、この非同期処理を実装・実現する方法について紹介します。
いいなと思ったら応援しよう！
