本「分散システム。 設計パターン

分散システムを使用しなければ、現代の世界は考えられません。 最も単純なモバイルアプリケーションでさえ、クラウドストレージに接続するためのAPIを備えています。 ただし、分散システムの設計は依然として芸術であり、正確な科学ではありません。 その下に真剣な基礎をもたらす必要性は長い間待ち望まれており、分散システムの作成、サポート、運用に自信を持ちたいなら、この本から始めてください！



クラウドテクノロジーおよびKubernetesの評判の高い専門家であるBrendan Burnsは、この小さな作業で、分散システムの適切な設計に必要な絶対的な最小値を設定します。 この本は、分散システムを設計する時代を超えたパターンについて説明しています。 このようなシステムをゼロから作成するだけでなく、既存のシステムを効果的に変換するのにも役立ちます。

抜粋 デコレータパターン。 リクエストまたはレスポンスを変換する

FaaSは、入力データを処理して他のサービスに転送する単純な機能が必要な場合に理想的です。 この種類のパターンは、別のサービスによって送信または受信されたHTTP要求を展開または装飾するために使用できます。 このパターンを図に概略的に示します。 8.1。



ところで、プログラミング言語では、このパターンにいくつかの類推があります。 特に、Pythonには、要求または応答デコレーターと機能的に類似した関数デコレーターがあります。 装飾変換は状態を保存せず、サービスの開発時に事実上追加されることが多いため、FaaSとしての実装に最適です。 さらに、FaaSの軽さは、サービスとより密接に統合するデコレーターが見つかるまで、さまざまなデコレーターを試すことができることを意味します。









HTTP RESTful APIリクエストの入力パラメーターにデフォルト値を追加すると、Decoratorパターンの利点が実証されます。 多くのAPIリクエストには、呼び出し元によって指定されていない場合、適切な値を入力する必要があるフィールドがあります。 たとえば、フィールドをデフォルトのtrueに設定します。 デフォルトの空のフィールド値はnullであり、通常はfalseと解釈されるため、従来のJSONではこれを実現するのが困難です。 この問題を解決するには、APIサーバーの前またはアプリケーション自体のコードにデフォルト値を代入するロジックを追加します（たとえば、（field == null）field = true）。 ただし、これらのアプローチはどちらも最適ではありません。これは、デフォルトの置換メカニズムが概念的にリクエスト処理から独立しているためです。 代わりに、FaaS Decoratorパターンを使用して、ユーザーとサービス実装の間の途中でリクエストを変換できます。



単一ノードパターンのセクションで前述した内容を考慮すると、アダプターコンテナーの形式で既定の置換サービスを設計しなかった理由を疑問に思うかもしれません。 このアプローチは理にかなっていますが、デフォルトのルックアップサービスのスケーリングとAPIサービス自体のスケーリングが互いに依存するようになることも意味します。 デフォルト値を置き換えることは計算上簡単な操作であり、多くの場合、サービスの多くのインスタンスは必要ありません。

この章の例では、kubeless FaaSフレームワーク（https://github.com/kubeless/kubeless）を使用します。 Kubelessは、Kubernetesコンテナオーケストレーターサービスの上に展開されます。 すでにKubernetesクラスターを準備している場合は、対応するサイト（https://github.com/kubeless/kubeless/releases）からダウンロードできるKubelessのインストールに進みます。 kubeless実行可能ファイルを入手したら、kubeless installコマンドを使用してクラスターにインストールできます。



Kubelessは、サードパーティのKubernetes APIアドオンとしてインストールされます。 これは、インストール後にkubectlコマンドラインツールの一部として使用できることを意味します。 たとえば、クラスターにデプロイされた関数は、kubectl get functionsコマンドを実行することで確認できます。 現在、クラスターにデプロイされている機能はありません。

ワークショップ 要求処理前のデフォルト値の置換

ユーザーが値を設定していないパラメーターをRESTful呼び出しでデフォルト値に置き換える例により、FaaSのDecoratorパターンの有用性を実証できます。 FaaSでは、これは非常に簡単です。 デフォルトのルックアップ関数はPythonで書かれています：

#  -,   #   def handler(context): #    obj = context.json #   "name" ,   #   if obj.get("name", None) is None: obj["name"] = random_name() #    'color',   #   'blue' if obj.get("color", None) is None: obj["color"] = "blue" #  API-     #   #    return call_my_api(obj)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この関数をdefaults.pyというファイルに保存します。 call_my_api呼び出しを、必要なAPIの呼び出しに置き換えてください。 このデフォルトの置換関数は、次のコマンドを使用してkubeless関数として登録できます。

 kubeless function deploy add-defaults \ --runtime python27 \ --handler defaults.handler \ --from-file defaults.py \ --trigger-http
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テストするには、kubelessツールを使用できます。

 kubeless function call add-defaults --data '{"name": "foo"}'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

デコレータパターンは、デフォルト値の検証や置換などの追加機能を使用して、既存のAPIを簡単に調整および拡張できることを示しています。

イベント処理

ほとんどのシステムはクエリ指向です-ユーザーとAPIリクエストの連続フローを処理します。 それにもかかわらず、イベント指向のシステムはかなりあります。 私にとっては、リクエストとイベントの違いはセッションのコンセプトにあります。 要求は、より大きな対話プロセス（セッション）の一部です。 一般的な場合、各ユーザーリクエストは、WebアプリケーションまたはAPI全体とやり取りするプロセスの一部です。 私は、イベントを本質的に非同期の「ワンタイム」と見なしています。 イベントは重要であり、それに応じて処理する必要がありますが、イベントは相互作用の主要なコンテキストから切り離されており、それらに対する答えはしばらくしてから来ます。 イベントの例としては、特定のサービスへのユーザーのサブスクリプションがあります。これにより、グリーティングレターが送信されます。 共有フォルダーにファイルをアップロードすると、このフォルダーのすべてのユーザーに通知が送信されます。 または、再起動のためにコンピューターを準備します。これにより、適切なアクションが必要であることをオペレーターまたは自動システムに通知します。



これらのイベントはほとんど独立しており、内部状態がなく、頻度も非常に変動するため、イベント指向のFaaSアーキテクチャでの作業に最適です。 多くの場合、追加の機能を提供するため、または新たなイベントに応じてデータをバックグラウンドで処理するために、「戦闘」アプリケーションサーバーの隣に配置されます。 さらに、新しいタイプの処理済みイベントが常にサービスに追加されるため、機能の展開が容易なため、イベントハンドラーの実装に適しています。 また、各イベントは概念的に他のイベントから独立しているため、機能に基づいて構築されたシステム内の関係を強制的に弱めることにより、概念の複雑さを軽減でき、開発者は特定のタイプのイベントのみを処理するために必要な手順に集中できます。



イベント指向コンポーネントを既存のサービスに統合する特定の例は、2要素認証の実装です。 この場合、イベントはユーザーのシステムへのログインになります。 サービスはこのアクションのイベントを生成し、ハンドラー関数に渡すことができます。 ハンドラーは、送信されたコードとユーザーの連絡先情報に基づいて、テキストメッセージの形式で認証コードを送信します。

ワークショップ 2要素認証の実装

二要素認証は、システムに入るには、ユーザーが知っているもの（パスワードなど）と持っているもの（電話番号など）が必要であることを示します。 攻撃者はアクセスするためにパスワードと電話番号の両方を盗む必要があるため、2要素認証は単なるパスワードよりもはるかに優れています。



2要素認証の実装を計画する場合、ランダムコードを生成するためのリクエストを処理し、ログインサービスに登録して、ユーザーにメッセージを送信する必要があります。 この機能を実装するコードをログインサービス自体に直接追加できます。 これによりシステムが複雑になり、モノリシックになります。 メッセージの送信は、ログインWebページを生成するコードと同時に実行する必要があります。これにより、一定の遅延が生じる場合があります。 この遅延は、システムとのユーザーインタラクションの品質を低下させます。



乱数を非同期的に生成し、ログインサービスに登録してユーザーの電話に送信するFaaSサービスを作成することをお勧めします。 したがって、ログインサーバーは、FaaSサービスへの非同期リクエストを実行するだけで済み、コードの登録と送信という比較的遅いタスクを並行して実行します。

これがどのように機能するかを確認するには、次のコードを検討してください。

 def two_factor(context): #     code = random.randint(1 00000, 9 99999) #        user = context.json["user"] register_code_with_login_service(user, code) #      Twillio account = "my-account-sid" token = "my-token" client = twilio.rest.Client(account, token) user_number = context.json["phoneNumber"] msg = ", {},   : {}.".format(user, code) message = client.api.account.messages.create(to=user_number, from_="+1 20652 51212", body=msg) return {"status": "ok"}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、キューブレスでFaaSを登録します。

 kubeless function deploy add-two-factor \ --runtime python27 \ --handler two_factor.two_factor \ --from-file two_factor.py \ --trigger-http
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この関数のインスタンスは、ユーザーが正しいパスワードを入力した後、JavaScriptのクライアントコードから非同期に生成できます。 Webインターフェースはコードを入力するためのページをすぐに表示でき、ユーザーはコードを受け取るとすぐに、このコードが既に登録されているログインサービスをユーザーに通知できます。



そのため、FaaSアプローチは、ユーザーがシステムにログオンしたときに開始される単純な非同期のイベント指向サービスの開発を大幅に促進しました。

イベントコンベア

実際、疎結合イベントのパイプラインとして考えるのが簡単なアプリケーションがいくつかあります。 多くの場合、イベントパイプラインは古き良きフローチャートに似ています。 これらは、関連するイベントの同期の有向グラフとして表すことができます。 イベントパイプラインパターンのフレームワーク内では、ノードは関数に対応し、それらを接続するアークはHTTP要求または他の種類のネットワークコールに対応します。



コンテナの要素間には、原則として共通の状態はありませんが、リポジトリ内の検索が実行されるベースとなる共通のコンテキストまたは他の参照ポイントが存在する場合があります。



このようなパイプラインアーキテクチャとマイクロサービスアーキテクチャの違いは何ですか？ 2つの重要な違いがあります。 サービス機能と継続的に実行されるサービスの最初の最も重要な違いは、イベントパイプラインが本質的にイベント駆動型であることです。 それどころか、マイクロサービスアーキテクチャは、常に機能する一連のサービスを意味します。 さらに、イベントパイプラインは非同期で、さまざまなイベントをバインドできます。 Jiraのアプリケーション承認をマイクロサービスアプリケーションに統合する方法を想像するのは困難です。 同時に、イベントパイプラインにどのように統合されるかを簡単に想像できます。



例として、ソースイベントがバージョン管理システムへのコードのロードであるパイプラインを考えます。 このイベントにより、コードが再構築されます。 アセンブリには数分かかる場合があります。その後、イベントが生成され、アセンブルされたアプリケーションのテスト機能がトリガーされます。 アセンブリの成功に応じて、テスト機能はさまざまなアクションを実行します。 アセンブリが成功した場合、アプリケーションが作成されます。アプリケーションの新しいバージョンを使用するには、承認が必要です。 アプリケーションを閉じることは、新しいバージョンを運用するためのシグナルとして機能します。 アセンブリが失敗した場合、Jiraは検出されたエラーを要求し、パイプラインは終了します。

ワークショップ 新しいユーザーを登録するためのパイプラインを実装する

新しいユーザーを登録するための一連のアクションを実装するタスクを検討してください。 新しいアカウントを作成すると、ウェルカムメールの送信など、一連のアクション全体が常に実行されます。 たとえば、製品の新しいバージョン（スパムとも呼ばれます）についての電子メールニュースレターを購読するなど、毎回実行されるとは限らないいくつかのアクションもあります。



1つのアプローチには、新しいアカウントを作成するためのモノリシックサービスの作成が含まれます。 このアプローチでは、1つの開発チームがサービス全体を担当し、サービス全体も展開されます。 これにより、実験を行ったり、ユーザーがアプリケーションとやり取りするプロセスを変更したりすることが難しくなります。



複数のFaaSサービスのイベントパイプラインとしてのユーザーログインの実装を検討してください。 この分離により、ユーザー作成機能はユーザーのログイン中に何が起こるかわかりません。 彼女には2つのリストがあります。

• 必要なアクションのリスト（ウェルカムメールの送信など）。
• オプションのアクションのリスト（ニュースレターの購読など）。

これらの各アクションもFaaSとして実装されており、アクションのリストはHTTPコールバック関数のリストにすぎません。 したがって、ユーザー作成関数の形式は次のとおりです。

 def create_user(context): #      for key, value in required.items(): call_function(value.webhook, context.json) #    #     for key, value in optional.items(): if context.json.get(key, None) is not None: call_function(value.webhook, context.json)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各ハンドラーは、FaaSの原則に従って実装することもできます。

 def email_user(context): #    user = context.json['username'] msg = ', {}, ,     !".format(user) send_email(msg, contex.json['email]) def subscribe_user(context): #    email = context.json['email'] subscribe_user(email)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この方法で分解されたFaaSサービスは、はるかに単純になり、コードの行数が少なくなり、特定の1つの機能の実装に焦点が当てられます。 マイクロサービスのアプローチにより、コードの記述は簡単になりますが、3つの異なるマイクロサービスの展開と管理が困難になる可能性があります。 ここで、FaaSアプローチは、その使用の結果として、コードの小さな部分を管理することが非常に簡単になるため、栄光の中で証明されています。 イベントパイプラインの形式でユーザーを作成するプロセスを視覚化すると、パイプライン内の機能ごとのコンテキストの変化を追跡するだけで、ユーザーログイン中に正確に何が起こるかを広く理解できます。



»本の詳細については、出版社のウェブサイトをご覧ください

» コンテンツ

» 抜粋



デザイナー向けクーポンの20％割引- デザインパターン



本の紙版が支払われると、電子版の本が電子メールで送信されます。