マイクロサービスとストアドプロシージャ

ストアドプロシージャは、マイクロサービスアーキテクチャで悪い習慣と見なされますか？

私の考えは次のとおりです。

• マイクロサービスに関するほとんどの書籍では、マイクロサービスごとに1つのデータベースを推奨しています。通常、ストアドプロシージャはモノリシックデータベースで機能します。

• 繰り返しますが、ほとんどのマイクロサービスアーキテクチャの本は、自律的で疎結合である必要があると述べています。特にOracleで作成されたストアドプロシージャを使用すると、マイクロサービスとそのテクノロジが緊密に結合されます。

• 私が読んだほとんどのマイクロサービスアーキテクチャの本は、マイクロサービスをビジネス指向（ドメイン駆動設計（DDD）を使用して設計）にすることを推奨しています。データベースのストアドプロシージャにビジネスロジックを移動することにより、これはもはや事実ではありません。

これについて何か考えはありますか？

マイクロサービスでストアドプロシージャを使用することを明示的に禁止または主張するものはありません。

免責事項：開発者のPOVのストアドプロシージャは好きではありませんが、マイクロサービスとはまったく関係ありません。

ストアドプロシージャは通常、モノリスデータベースで機能します。

あなたは論理的な誤りに屈していると思います。

ストアドプロシージャは最近減少傾向にあります。まだ使用されているほとんどのストアドプロシージャは、保持されている古いコードベースのものです。当時、モノリシックデータベースは、マイクロサービスが普及したときと比べてはるかに普及していました。

ストアドプロシージャとモノリシックデータベースはどちらも古いコードベースで発生するため、頻繁に一緒に表示されます。しかし、それは因果関係ではありません。モノリシックデータベースがあるため、ストアドプロシージャは使用しません。ストアドプロシージャを使用しているため、モノリシックデータベースはありません。

マイクロサービスに関するほとんどの書籍では、マイクロサービスごとに1つのデータベースを推奨しています。

これらの小さなデータベースがストアドプロシージャを保持できない技術的な理由はありません。

前述したように、ストアドプロシージャは好きではありません。私はそれらが面倒で、将来のメンテナンスに耐えることがわかります。多くの小さなデータベースにsprocを広めることは、私がすでに気に入らない問題をさらに悪化させると思います。しかし、それはそれができないという意味ではありません。

繰り返しますが、ほとんどのマイクロサービスアーキテクチャの本は、自律的で疎結合である必要があると述べています。特にOracleで作成されたストアドプロシージャを使用すると、マイクロサービスとそのテクノロジが緊密に結合されます。

一方、マイクロサービスが使用するORMについては、同じ議論をすることができます。すべてのORMがすべてのデータベースをサポートするわけではありません。カップリング（具体的にはそのタイトネス）は相対的な概念です。それはあなたが合理的にできる限りゆるいことの問題です。

Sprocは、マイクロサービスに関係なく、一般に密結合の影響を受けます。一般的にはsprocに対してはお勧めしますが、特にマイクロサービスを使用しているためではありません。これは以前と同じ議論です：sprocは（一般的に）進むべき道ではないと思いますが、それは単に私の偏見かもしれませんし、マイクロサービスとは関係ありません。

ほとんどのmsaの本（私が読んだ）は、マイクロサービスをビジネス指向（dddを使用して設計）にすることを推奨しています。データベースのストアドプロシージャにビジネスロジックを移動することにより、これはもはや事実ではありません。

これは、常にsprocについての私の主な不満でした。データベースのビジネスロジックです。意図しないときでさえ、それはどういうわけか常にそのようになる傾向があります。

ただし、マイクロサービスを使用するかどうかに関係なく、この不満は存在します。それがより大きな問題のように見える唯一の理由は、マイクロサービスがあなたにあなたのアーキテクチャ全体を近代化することを強いるからです。

ソフトウェアを書くには、テクノロジーと緊密に結合する必要があります。

少なくとも、内部で開発されているプログラミング言語によって提供されるランタイム環境に対して。

より一般的には、マイクロサービスはいくつかのテクノロジーと密接に結びついていることがわかります。

• 高レベルのHTTP / SSL / SOAPプロトコル実装を提供するネットワークサービスフレームワーク
• 永続性を提供するリポジトリ/ ORM / DAOフレームワーク。
• データを操作するためのツールを提供するデータ操作フレームワーク。
• マルチタスク、ファイルシステム、メモリ、GPUコンピューティング、拡張カードなどのOSリソースへのアクセスを提供するプロセス/スレッド化/ OSフレームワーク...

そして、それは最低限のマイクロサービスを作ることです。

ストアドプロシージャ

ストアドプロシージャは、使用するかどうかを選択できる別のテクノロジにすぎません。魔法のようにコードをモノリシックにしたり、マイクロにしたりすることはありません。

それは何ですか：

• 別の技術。アプリケーションに存在する各テクノロジーは、特定のプログラマーがそのテクノロジーミックスを読んで理解し、賢明な設計選択をする可能性を減らします。
• 異なるプログラミングパラダイムを使用する言語。専門家でない人が自分の命令型、機能的、オブジェクト指向などの視点を試そうとするのはあまりにも簡単です。
• API。これは、コードベースの他のクラスと同様に維持する必要があります。また、データベースが非汎用インターフェースを提供していることも意味します。これにより、データベースエンジン自体の置き換えと、メモリキャッシングなどの一般的な動作の透過的な適用の両方が難しくなります。
• アーティファクト。バージョン管理、テスト、および展開する必要があります。これは可能ですが、データベースは別のアプローチを必要とする生き物です。通常、元のファイルを単に削除して置き換えることはできません。多くの場合、システムを目的の状態に移行するには、時間をかけて慎重に変更を調整する必要があります。

これらはそれぞれ実際のコストです。場合によっては、コストは正当化できますが、そうでない場合もあります。

スクリプトエンジンをホストすることで、ほぼ同じコストを支払うことになります。唯一の削減は、ホスト言語と同じプログラミングパラダイムを選択できることです。

ビジネスの論理

データベースにビジネスルールを移動するのは悪い習慣です。ストアドプロシージャが原因ではありません。

データベースとビジネスロジックは異なるせん断レベルで動作するため、これは悪い習慣です。

• 成熟したアプリケーションのデータベースは何十年も使用されている可能性があります。通常、これらのシステムではエンジンが定期的に更新されますが、データベース自体は移行されました。それは最初から殺されて再建されませんでした。マイクロサービスがそれほど長く存続できない理由はありません。

• ビジネスルールの変化の速さと数十年を比較してください。私の経験では、古いビジネスルールはおそらく数年前のものですが、ほとんどの場合急速に変更されますが、次に変更されるルールはわかりません。規制当局からの新しい要件、廃止される古い製品、レターヘッドの変更、上司に報告する従業員の数などの変更など...

ビジネスロジックがせん断層全体、特に低速で長寿命の層に分散している場合、変更に対する抵抗が発生します。これは必ずしも悪いことではありません。結局のところ、ビジネスロジックがゼロのデータベースはトリプルストアだけです。

テーブルスキーマを指定するだけの行為は、ビジネスロジックをデータベースに移動することです。

建築

ソリューションを作成して維持するために、多くのツールを必要とせず、解決するのが難しくなりすぎることなく、適切な問題に適切なツールを使用することに取り組んでいます。

これは簡単ではありません。

しかし、考えられないことを考えてみましょう。複数の言語に分散されたビジネスロジックをどのように維持しますか？

• カタログ...これにより、各ビジネスルールの実装を追跡および維持できます。
• テスト...実装場所や方法に関係なく、各ビジネスルールに対して使用できます。
• 参照実装..不一致が見つかったときに、真実のソース（または少なくとも議論のソース）が存在するようにします。

しかし、これにはコストもかかります。

• ビジネスルールに多くの実装を許可する方が良いでしょうか？それはそれぞれチームのスキルとフレームワークのプロビジョニングを活用できますが、多くの小さな気まぐれを避けるために厳しい品質管理が必要ですか？
• それとも、単一の言語で書かれた真実の単一の情報源を持つ方が良いでしょうか？実装するのに間違いなく安価でありながら、単一の障害の原因でもあり、それ自体が異なるプラットフォーム、フレームワーク、またはまだ発明されていないツールに直面した場合の変化に抵抗するモノリシックなコンポーネントですか？

答えは、ストアドプロシージャを使用するいくつかのマイクロサービスを実際に維持していると言って、序文にします。また、キャリアのさまざまな時点で多くのストアドプロシージャを作成しましたが、間違った使い方をすると非常に間違った方向に進む可能性があることは間違いありません。

短い答えは、いや、マイクロサービスアーキテクチャではストアドプロシージャが本質的に悪くないということです。しかし、あなたは理解する必要があります：

1. ストレージエンジンの代替に障害を追加しています。運用またはパフォーマンスの特性または機能の制限によってストレージエンジンを切り替える必要がある場合、多くの新しいコードを作成してテストするため、コストが高くなります。複数のストレージエンジンを実行する（移行フェーズ中またはパフォーマンスニーズに基づいてアクティビティを分離するために）場合、パフォーマンスの問題がある2フェーズコミット（2PC）を使用しない限り、一貫性の問題が発生する可能性があります。
2. 維持する別のAPIがあるので、依存関係が壊れる可能性があります。プロシージャのパラメータのタイプを追加、削除、または変更すると、既存のコードが破損する可能性があります。テーブルとクエリでも同じことが起こりますが、ツールは、問題が発生する可能性のある場所を追跡するのにあまり役に立たない場合があります。ストアドプロシージャの問題は通常、実行時、開発/展開プロセスの非常に遅い段階で発見されます。
3. データベースのアクセス許可がさらに複雑になりました。プロシージャは、ログインしているユーザーまたは他のロールとして実行されますか？これについて考え、管理する必要があります（できれば自動化された方法で）。
4. 安全に新しいバージョンに移行できる必要があります。多くの場合、プロシージャを削除して再作成する必要があります。この場合も、アクセス許可によって問題が発生する可能性があります。
5. 失敗した移行のロールバックは、余分な労力を意味する場合があります。実稼働環境が開発者から分離されると、事態はさらに困難になります。

これらは、価値のあるストアドプロシージャの使用例です。

1. 編集履歴の実施（監査ログ）。トリガーはこの目的で一般的に使用され、トリガーはストアドプロシージャです。一部のデータベースでは、アプリケーションロールの挿入と更新を完全に禁止することもできます。クライアントは、適切な権限を持つ別のロールとして実行され、必要なすべての動作を強制するプロシージャを実行します。
2. チェック制約の拡張。これにより、ビジネスロジックの領域に入る可能性がありますが、データベースの組み込み制約ツールでは必要なものに十分でない場合があります。多くの場合、チェックを表現する最良の方法は命令型コードを使用することであり、アプリケーションに依存してそれを行う場合は、不良データを入れてしまうリスクがあります。
3. ビューが不適切または複雑すぎる場合の複雑なクエリのカプセル化。正しいビューが、ストアドプロシージャではるかに理解しやすいように表現できる非常に複雑なSQLを必要とするいくつかのケースを見てきました。これはおそらくまれですが、実際に発生します。

一般的に、最初にビューを試して、必要な場合にのみ手順に頼ることをお勧めします。適切に設計されたビューは、実際にはAPIとして機能し、基礎となるテーブルのクエリ方法の詳細を抽象化します。ストアドプロシージャを使用してAPI（ビュー）を拡張することは、状況によっては意味があります。クエリ結果からアプリケーションのデータモデルへのマッピングデータ全体をバイパスして、SQLクエリから直接JSONを送信することも可能です。それが良いアイデアであるかどうかは、あなた自身のニーズに基づいて決定するためのものです。

既に自動化されたツールを使用してデータベースリソース（スキーマ、アクセス許可など）を管理しているはずなので、いや、ストアドプロシージャは本質的にマイクロサービスにとって悪いことではありません。

ストアドプロシージャは実装の詳細です。ファイルシステムのどこかに保存されているデータベース関数、ラムダ、またはシェルスクリプトはすべて実装の詳細であり、アーキテクチャには無関係です。

マイクロサービスに関するほとんどの書籍では、マイクロサービスごとに1つのデータベースを推奨しています。

それでは、これらのデータベースにストアドプロシージャをコーディングできます。

繰り返しますが、ほとんどのマイクロサービスアーキテクチャの本は、自律的で疎結合である必要があると述べています

ビジネス機能、開発のライフサイクル、管理、展開、チームの場所などの間。実装の詳細とは関係ありません。マイクロサービスは技術的な問題を解決しません（その逆）。彼らは管理と市場投入までの時間の問題を解決するようになります。それは戦略であり、戦術ではありません。最小限のコストでフェイルファーストする方法。特定のビジネス機能が無価値であることが証明された場合、他の機能、展開、プロジェクトの管理、リリースを台無しにすることなく、それを削除します...

「分割」はすでにデカップリングエージェントのように動作することに注意してください。AにはOracleが、BにはMongoDBの2つのサービスがあるとします。デカップリングの黄金律を破らなければ、Bにほとんど影響を与えずにA + Oracleをドロップできるはずです。

特にOracleで作成されたストアドプロシージャを使用すると、マイクロサービスとそのテクノロジが緊密に結合されます。

ベンダーがロックインする可能性があります。多くの場合、ベンダーは、歴史的または契約上の理由により、ビジネスによって課せられます¹。コードをベンダーにロックしない方法を知ることが重要です。たとえば、一部のORMとフレームワークは、データベースの組み込み関数と機能を隠す新しいクエリ言語を実装しています。

ただし、当社のサービスが十分に微細であれば、ベンダーのロックインは全体のごく一部に影響を与えるため、もはや問題ではありません。迅速に交換（または分離）できる小さな部品。

私が読んだほとんどのMSAの本は、マイクロサービスをビジネス指向（DDDを使用して設計）にすることを推奨しています。

それはビジネス主導である必要があります。すべてのビジネスがDDDを利用するわけではありません。DDDとマイクロサービスは多くの点で重複していますが、因果関係ではありません。貧血サービスで構成されるマイクロサービスエコシステムになる可能性があります。または、両方の組み合わせで構成されます：複雑なドメインを実装するサービスと、DBJから直接POJOを提供する無意味なサービス。それには何の問題もありません。

本に関しては、戦略の実行にのみ焦点を当てています。戦術- 分散コンピューティングを活用する方法-それを成功させる方法ですが、それらは（通常）戦略にとらわれません。戦略は会社によって異なり、開発者に依存することはめったにありません。ですから、私たちは、本が私たちの特定のニーズ、要件、制約に言っていることを外挿し、適応させなければなりません。目標は、ビジネス戦略を収益性と持続可能性にすることです。

どんなアーキテクチャでも目的を達成する手段であることを常に念頭に置いてください。ビジネスルール。ファッションや芸術への愛のためにマイクロサービスエコシステムを構築することはありません。

マイクロサービスとは何の関係もありません。

サービスにDBがサービスの基盤であり、データアクセス層とビジネスロジック層が最上位にある「古いスタイル」の階層化アーキテクチャがある場合、ストアドプロシージャは意味をなすことができます。このようなアーキテクチャでのサービスとデータベース間のインターフェイスは、サービスの最も内側の詳細に非常に固有です。通常、サポートされるデータベースの種類ごとにサービス固有のアダプターがあり、アダプターによって公開されるAPIの特異性により、基になるレイヤーでストアドプロシージャを使用できるようになります。

そのようなアーキテクチャには多くの問題があります。最も重要なことは、ほとんどのロジックの単体テストが非常に困難になることです。これらのアーキテクチャはもはや好まれません。

新しいスタイルの「クリーンアーキテクチャ」、「オニオンアーキテクチャ」などを使用している場合、データベースは、外部層で指定された依存関係が注入されます。外側の層で定義されているため、データベースに提供されるインターフェースはgenericでなければなりません。サービスの最も内側の詳細を反映することはできません。これらの詳細は、アーキテクチャの最も外側の層から隠されている必要があるためです。任意のデータベースまたは単体テストハーネスで動作する汎用ストアドプロシージャインターフェイスを定義することは非常に難しく、実際には必要ではないため、これらの種類のアーキテクチャではストアドプロシージャが実用的でないことがよくあります。

マイクロサービスとの関係は、マイクロサービスが新しくて優勢であるということです-私たちはモノリスをもうしません-そしてこれらの新しいアーキテクチャースタイルもまた優勢であるということです-私たちはもはやフラットレイヤーをしません。