マイクロサービスマクロの問題

わずか20年で、ソフトウェア開発は、単一のデータベースと一元化された状態を備えたアーキテクチャモノリスから、すべてが多数のコンテナ、サーバー、データセンター、さらには大陸に分散されるマイクロサービスに移行しました。分散によりスケーリングが容易になりますが、まったく新しい課題も発生します。その多くは、以前はモノリスで解決されていました。



ネットワーク化されたアプリケーションの歴史を簡単に見て、今日ここにたどり着いた方法を理解しましょう。次に、Temporalで使用されるステートフル実行モデルについて説明します。そしてそれがサービス指向アーキテクチャ（SOA）の問題をどのように解決するか。Temporalで食料品部門を経営しているので偏見があるかもしれませんが、このアプローチは未来だと思います。

短い歴史のレッスン

20年前、開発者はほとんどの場合、モノリシックアプリケーションを作成していました。これは、ローカル環境でのプログラミング方法と同様の、シンプルで一貫性のあるモデルです。モノリスはその性質上、単一のデータベースに依存しています。つまり、すべての状態が一元化されています。単一のトランザクション内で、モノリスはその状態のいずれかを変更できます。つまり、モノリスは、機能したかどうかに関係なく、バイナリの結果を返します。矛盾の余地はありません。つまり、モノリスのすばらしい点は、トランザクションの失敗による一貫性のない状態が発生しないことです。そしてこれは、開発者がコードを書く必要がなく、常にさまざまな要素の状態を推測する必要がないことを意味します。



長い間、モノリスは理にかなっています。接続されているユーザーはまだ多くないため、ソフトウェアのスケーリング要件は最小限でした。最大のソフトウェアの巨人でさえ、現代の基準ではわずかなシステムを運用していました。アマゾンやグーグルのような一握りの会社だけが大規模なソリューションを使用しましたが、それらは規則の例外でした。

ソフトウェアとしての人々

過去20年間、ソフトウェア要件は絶えず増大しています。今日、アプリケーションは最初からグローバル市場で機能するはずです。 TwitterやFacebookなどの企業は、24時間年中無休のオンラインを前提条件としています。アプリはもはや何も提供せず、それ自体がユーザーエクスペリエンスになりました。今日のすべての企業はソフトウェア製品を持っている必要があります。 「信頼性」と「可用性」はもはやプロパティではなく、要件です。



残念ながら、「拡張性」と「可用性」が要件に追加されると、モノリスは崩壊し始めました。開発者も企業も同様に、爆発的な世界的成長と厳しいユーザーの期待に対応する方法を見つける必要がありました。スケーリングに関連する新たな問題を軽減する代替アーキテクチャを探す必要がありました。



マイクロサービス（まあ、サービス指向のアーキテクチャ）が答えでした。当初は、アプリケーションを独立してスケーリングできる比較的自己完結型のモジュールに分割できるため、優れたソリューションのように見えました。また、各マイクロサービスは独自の状態を維持しているため、アプリケーションは単一のマシンの容量に制限されなくなりました。開発者はついに、接続数の増加に合わせて拡張できるプログラムを作成できるようになりました。マイクロサービスはまた、責任の透明性とアーキテクチャの分離により、チームと企業に作業の柔軟性をもたらしました。

無料のチーズはありません

マイクロサービスは、ソフトウェアの成長を妨げてきたスケーラビリティと可用性の問題を解決しましたが、物事はクラウドレスではありませんでした。開発者は、マイクロサービスに重大な欠陥があることに気づき始めました。



モノリスには通常、1つのデータベースと1つのアプリケーションサーバーがあります。また、モノリスは分割できないため、スケーリングする方法は2つしかありません。

• 垂直：ハードウェアをアップグレードして、スループットまたは容量を増やします。このスケーリングは効果的ですが、コストがかかります。また、アプリケーションを成長させ続ける必要がある場合でも、問題が永久に解決するわけではありません。そして、十分に拡張すると、最終的にアップグレードするのに十分な機器がなくなります。
• : , . , .

マイクロサービスは異なります。その価値は、互いに独立してスケーリングおよび管理される多くの「タイプ」のデータベース、キュー、およびその他のサービスを持つ機能にあります。ただし、マイクロサービスに切り替えるときに最初に気づき始めた問題は、今ではあらゆる種類のサーバーとデータベースを処理する必要があるという事実でした。



長い間、すべてが偶然に任され、開発者とオペレーターは自分たちで立ち上がった。マイクロサービスによって引き起こされるインフラストラクチャ管理の問題に取り組むことは困難であり、せいぜいアプリケーションの信頼性を低下させます。



ただし、供給は需要に応じて発生します。マイクロサービスが普及すればするほど、インフラストラクチャの問題を解決する意欲のある開発者が増えます。ゆっくりと、しかし確実に、ツールが出現し始め、Docker、Kubernetes、AWSLambdaなどのテクノロジーがギャップを埋めました。これらにより、マイクロサービスアーキテクチャの操作が非常に簡単になりました。開発者は、コンテナやリソースと連携するための独自のコードを作成する代わりに、事前に構築されたツールに依存できます。2020年に、インフラストラクチャの可用性がアプリケーションの信頼性に干渉しなくなるというマイルストーンにようやく到達しました。完璧に！





もちろん、私たちはまだ完全に安定したソフトウェアのユートピアに住んでいません。インフラストラクチャはもはやアプリケーションの不安定さの原因ではなく、アプリケーションコードが代わりに使用されています。

マイクロサービスに関する別の問題

モノリスでは、開発者は状態をバイナリの方法で変更するコードを記述します。何かが発生するか、発生しないかのどちらかです。また、マイクロサービスでは、状態がさまざまなサーバーに分散されます。アプリケーションの状態を変更するには、複数のデータベースを同時に更新する必要があります。 1つのデータベースが正常に更新され、他のデータベースがクラッシュして、一貫性のない中間状態が残る可能性があります。しかし、水平スケーリングの問題に対する唯一の解決策はサービスであったため、開発者には他の選択肢がありませんでした。





サービス全体に分散された状態の基本的な問題は、外部サービスへの各呼び出しが可用性に関してランダムな結果をもたらすことです。もちろん、開発者はコードの問題を無視して、外部依存関係へのすべての呼び出しが常に成功していると見なすことができます。ただし、一部の依存関係により、警告なしにアプリケーションが停止する可能性があります。したがって、開発者は、モノリスの時代からのコードを適応させて、トランザクションの途中での操作の失敗に対するチェックを追加する必要がありました。以下は、レース状態を回避するために、専用のmyDBストアから最後に記録された状態を継続的に取得することを示しています。残念ながら、この実装でさえ役に立ちません。 myDBを更新せずにアカウントの状態が変化すると、不整合が発生する可能性があります。

public void transferWithoutTemporal(
  String fromId, 
  String toId, 
  String referenceId, 
  double amount,
) {
  boolean withdrawDonePreviously = myDB.getWithdrawState(referenceId);
  if (!withdrawDonePreviously) {
      account.withdraw(fromAccountId, referenceId, amount);      
      myDB.setWithdrawn(referenceId);
  }
  boolean depositDonePreviously = myDB.getDepositState(referenceId);
  if (!depositDonePreviously) {
      account.deposit(toAccountId, referenceId, amount);                
      myDB.setDeposited(referenceId);
  }
}

残念ながら、エラーなしでコードを書くことは不可能です。また、コードが複雑になるほど、バグが発生する可能性が高くなります。ご想像のとおり、「ミドルウェア」で動作するコードは複雑であるだけでなく、複雑でもあります。少なくともある程度の信頼性は信頼性がないよりも優れているため、開発者はユーザーエクスペリエンスを維持するために、最初はバグのあるコードを作成する必要がありました。それは私たちに時間と労力を要し、雇用主は多額のお金を要します。マイクロサービスは美しく拡張できますが、開発者の楽しさと生産性、およびアプリケーションの信頼性が犠牲になります。



何百万もの開発者が、最も再発明されたホイールの1つであるボイラープレートの信頼性を再発明するために毎日時間を費やしています。マイクロサービスを操作するための最新のアプローチは、最新のアプリケーションの信頼性とスケーラビリティの要件を単に反映していません。

一時的

今、私たちは私たちの解決策にたどり着きました。 Stack Overflowによって承認されておらず、完璧であるとは主張していません。私たちは自分たちの考えを共有し、あなたの意見を聞きたいだけです。スタックよりもコードの改善に関するフィードバックを得るのに良い場所はありますか？



今日まで、上記の問題を解決せずにマイクロサービスを使用できるソリューションはありませんでした。クラッシュ状態をテストおよびエミュレートし、クラッシュを考慮してコードを記述できますが、これらの問題は依然として発生します。 Temporalがそれらを解決すると信じています。これは、マイクロサービスオーケストレーションのためのオープンソース（MITのナンセンス）ステートフル環境です。



Temporalには、選択したデータベースで実行されるステートフルバックエンドと、サポートされている言語の1つであるクライアントフレームワークの2つの主要コンポーネントがあります。アプリケーションは、クライアントフレームワークと、実行時にバックエンドの状態変更を自動的に保存する通常のレガシーコードを使用して構築されます。他のアプリケーションをビルドするときと同じ依存関係、ライブラリ、およびビルドチェーンを使用できます。正直なところ、バックエンドは高度に分散されているため、J2EE2.0とは異なります。実際、ほぼ無限の水平スケーリングを可能にするのはバックエンドの分布です。 Temporalは、Dockerインフラストラクチャ、Kubernetes、サーバーレスアーキテクチャと同様に、アプリケーションレイヤーに一貫性、シンプルさ、信頼性をもたらします。



Temporalは、マイクロサービスオーケストレーションのための信頼性の高いメカニズムを多数提供します。しかし、最も重要なことは、状態を維持することです。この関数は、イベントの発行を使用して、実行中のアプリケーションに対するステートフルな変更を自動的に保存します。つまり、Temporalが実行されているコンピューターがクラッシュした場合、コードは何も起こらなかったかのように自動的に別のコンピューターにジャンプします。これは、ローカル変数、実行スレッド、およびその他のアプリケーション固有の状態にも当てはまります。



例えさせてください。開発者として、あなたはおそらく今日、コードへの変更を追跡するためにSVNバージョン管理（つまりOG Git）に依存しています。 SVNは、重複を避けるために、新しいファイルを保存してから既存のファイルにリンクするだけです。 Temporalは、実行中のアプリケーションのステートフルな履歴のSVN（大まかな類推）のようなものです。コードがアプリケーションの状態を変更すると、Temporalはその変更（結果ではなく）をエラーなしで自動的に保存します。つまり、Temporalはクラッシュしたアプリケーションを復元するだけでなく、ロールバック、フォーク、その他多くのことを行います。そのため、開発者は、サーバーがクラッシュする可能性があることを期待してアプリケーションを構築する必要がなくなりました。



これは、文字を入力するたびに手動でドキュメントを保存する（Ctrl + S）からGoogleDocsの自動クラウド保存に切り替えるようなものです。手動で何も保存しなくなったという意味ではなく、このドキュメントに関連付けられているマシンが1つもなくなっただけです。ステートフル性とは、開発者がマイクロサービスのために作成する必要があった退屈な定型コードをはるかに少なく作成できることを意味します。さらに、特別なインフラストラクチャ（個別のキュー、キャッシュ、データベース）は不要になりました。これにより、操作や新機能の追加が簡単になります。また、紛らわしい特定の状態管理コードを理解する必要がないため、初心者を最新の状態にするのがはるかに簡単になります。



状態の保持は、「永続タイマー」の形式で実装されます。これは、コマンドで使用できるフェイルセーフメカニズムですWorkflow.sleep。とまったく同じように機能し sleepます。ただし、Workflow.sleepいつでも安全に安楽死させることができます。多くの一時的なユーザーは、数週間、さらには数年も眠っています。これは、実行時間の長いタイマーをTemporalストアに保存し、ウェイクアップするコードを追跡することで実現されます。繰り返しになりますが、サーバーがクラッシュした場合（またはサーバーをオフにした場合）でも、タイマーの期限が切れると、コードは使用可能なマシンに移動します。スリーププロセスはリソースを消費しません。ごくわずかなオーバーヘッドで数百万を超える可能性があります。抽象的すぎるように聞こえるかもしれません。そのため、動作する時間コードの例を次に示します。

public class SubscriptionWorkflowImpl implements SubscriptionWorkflow {
  private final SubscriptionActivities activities =
      Workflow.newActivityStub(SubscriptionActivities.class);
  public void execute(String customerId) {
    activities.onboardToFreeTrial(customerId);
    try {
      Workflow.sleep(Duration.ofDays(180));
      activities.upgradeFromTrialToPaid(customerId);
      while (true) {
        Workflow.sleep(Duration.ofDays(30));
        activities.chargeMonthlyFee(customerId);
      }
    } catch (CancellationException e) {
      activities.processSubscriptionCancellation(customerId);
    }
  }
}

状態を永続化することに加えて、Temporalは堅牢なアプリケーションを構築するための一連のメカニズムを提供します。アクティビティ関数はワークフローから呼び出されますが、アクティビティ内で実行されているコードはステートフルではありません。それらは持続しませんが、アクティビティには自動再試行、タイムアウト、およびハートビートが含まれます。アクティビティは、失敗する可能性のあるコードをカプセル化するのに非常に役立ちます。アプリが、多くの場合利用できないバンキングAPIを使用しているとしましょう。レガシーソフトウェアの場合、このAPIを呼び出すすべてのコードをtry / catchステートメント、再試行ロジック、およびタイムアウトでラップする必要があります。ただし、アクティビティからバンキングAPIを呼び出すと、これらのすべての機能がすぐに提供されます。呼び出しが失敗した場合、アクティビティは自動的に再試行されます。それはすべて素晴らしいですただし、信頼性の低いサービスを所有していて、それをDDoSから保護したい場合があります。したがって、アクティビティコールは、長いタイマーによってバックアップされるタイムアウトもサポートします。つまり、アクティビティの繰り返し間の一時停止は、数時間、数日、または数週間に達する可能性があります。これは、正常に実行する必要があるコードに特に役立ちますが、実行する必要がある速度がわかりません。



このビデオでは、Temporalのプログラミングモデルを2分で説明しています。





Temporalのもう1つの強みは、実行中のアプリケーションの可観測性です。オブザベーションAPIは、任意のワークフロー（実行可能かどうか）からメタデータをクエリするためのSQLのようなインターフェイスを提供します。プロセス内で独自のメタデータ値を定義および更新することもできます。オブザベーションAPIは、特に開発中のデバッグ時に、一時的なオペレーターと開発者にとって非常に便利です。監視は、クエリ結果に対するバッチアクションもサポートします。たとえば、リクエストが作成時刻>昨日であるすべてのワーカープロセスにkillシグナルを送信できます。 Temporalは、実行中のインスタンスからローカル変数の値をプルできる同期フェッチ機能をサポートしています。これは、IDEのデバッガーが実稼働アプリケーションで動作しているようなものです。たとえば、これは値を取得する方法ですgreeting 実行中のインスタンスの場合：

public static class GreetingWorkflowImpl implements GreetingWorkflow {

    private String greeting;

    @Override
    public void createGreeting(String name) {
      greeting = "Hello " + name + "!";
      Workflow.sleep(Duration.ofSeconds(2));
      greeting = "Bye " + name + "!";
    }

    @Override
    public String queryGreeting() {
      return greeting;
    }
  }

結論

マイクロサービスは優れており、開発者や企業が支払う生産性と信頼性を犠牲にして提供されます。Temporalは、開発者にマイクロサービスを提供する環境を提供することにより、この問題を解決するように設計されています。すぐに使用できるステートフルネス、自動障害、ウォッチドッグは、マイクロサービス開発をスマートにするTemporalが提供する機能のほんの一部です。