こんにちは。
最近仕事が忙しくて、ちょっと疲れているので、Azure Architecture Center で癒しを得ています。
ということで、癒されポイントをちょっと整理してみたいなって思いました。
ひとまず、Azure Architecture Center のドキュメントのリンクを貼っておきます。
Azure Architecture Center とは
Microsoft Azure に限らず、クラウドのサービスの上でシステムを構築する際には、クラウドならではのお作法を使った方が、よりクラウドの効果を得ることができます。
つまり、オンプレミスと同じ作り方だと、クラウドを使い切れないんです。
こんな部分を共有できるといいなぁって思いつつ、Azure のコンサルのお仕事とかをしてたりします。
別に、オンプレのシステムをそのままクラウドにあげてもいいんですけど、クラウドの長所を活かさないんだったら、なんでクラウドにマイグレーションするんだろうって思っちゃったりもします。
オンプレミスとクラウドの違い
Azure Architecture Center のドキュメントでも、従来のオンプレミスとと先進的なクラウドということで、その違いがこんな感じで書かれています。
まぁー、よく見る言葉が並んでますよね。
多分、一番わかりやすいのは、スケーラビリティだと思います。
オンプレの時は、スケールアウトは簡単にできないですよねー。サーバの台数には限りがありますから。だけど、クラウドを利用することでこの部分はかなり解放されているはずです。
でも、スケールが簡単にできるようになると、逆に困ることもあるんです。
スケールが簡単にできるようになって、新たに考えないといけないこと
たとえば、Web – DB のシステムがあるとします。
Web Apps で Web を構築し、DBは SQL Database とします。
この時に、Web Apps をオートスケールにしてスケールが出来た場合、SQL Database は、スケールしたWeb Apps 分の処理を1人で受けなきゃいけなくなります。もう、完全にフルボッコですよね。。。
これを防ぐんだったら、SQL Database の前に、Queue を入れてあげて交通整理してあげたいですよね～。
こんな感じで。
これ、Queue-Based Load Leveling pattern というデザインパターンです。
ある程度だったら、Azure SQL Database Serverless で十分だぜっ！ってなると超絶素敵なんだけど、どれくらいまでさばけるのか試したことないのでちょっとわからないや。
vCoreの数を見ると、結構こなせそうではあるけど。
ちなみに、Azure SQL Database Serverless については、SE の雑記の記事をご覧ください。
ちなみに、Azure SQL Database Serverless で、16vCoreを選べるようになったのは、最近みたいです。
Cloud Design Patterns
Queue-Based Load Leveling pattern について紹介しましたが、その他にも 全部で34 種類のデザインパターンが、Azure Architecture Center 以下のドキュメントで紹介されています。
※ 英語苦手な人は、↑のリンクのURLの en-us を ja-jp に返れば、少し古いかもしれないですが、日本語ドキュメントになるはずです。
タイトルと概要だけ、英語のまま載せちゃおっと。
- Ambassador
Create helper services that send network requests on behalf of a consumer service or application. - Anti-Corruption Layer
Implement a façade or adapter layer between a modern application and a legacy system. - Backends for Frontends
Create separate backend services to be consumed by specific frontend applications or interfaces. - Bulkhead
Isolate elements of an application into pools so that if one fails, the others will continue to function. - Cache-Aside
Load data on demand into a cache from a data store - Circuit Breaker
Handle faults that might take a variable amount of time to fix when connecting to a remote service or resource. - Claim Check
Split a large message into a claim check and a payload to avoid overwhelming a message bus. - Compensating Transaction
Undo the work performed by a series of steps, which together define an eventually consistent operation. - Competing Consumers
Enable multiple concurrent consumers to process messages received on the same messaging channel. - Compute Resource Consolidation
Consolidate multiple tasks or operations into a single computational unit - CQRS
Segregate operations that read data from operations that update data by using separate interfaces. - Event Sourcing
Use an append-only store to record the full series of events that describe actions taken on data in a domain. - External Configuration Store
Move configuration information out of the application deployment package to a centralized location. - Federated Identity
Delegate authentication to an external identity provider. - Gatekeeper
Protect applications and services by using a dedicated host instance that acts as a broker between clients and the application or service, validates and sanitizes requests, and passes requests and data between them. - Gateway Aggregation
Use a gateway to aggregate multiple individual requests into a single request. - Gateway Offloading
Offload shared or specialized service functionality to a gateway proxy. - Gateway Routing
Route requests to multiple services using a single endpoint. - Health Endpoint Monitoring
Implement functional checks in an application that external tools can access through exposed endpoints at regular intervals. - Index Table
Create indexes over the fields in data stores that are frequently referenced by queries. - Leader Election
Coordinate the actions performed by a collection of collaborating task instances in a distributed application by electing one instance as the leader that assumes responsibility for managing the other instances. - Materialized View
Generate prepopulated views over the data in one or more data stores when the data isn’t ideally formatted for required query operations. - Pipes and Filters
Break down a task that performs complex processing into a series of separate elements that can be reused. - Priority Queue
Prioritize requests sent to services so that requests with a higher priority are received and processed more quickly than those with a lower priority. - Publisher/Subscriber
Enable an application to announce events to multiple interested consumers asynchronously, without coupling the senders to the receivers. - Queue-Based Load Leveling
Use a queue that acts as a buffer between a task and a service that it invokes in order to smooth intermittent heavy loads. - Retry
Enable an application to handle anticipated, temporary failures when it tries to connect to a service or network resource by transparently retrying an operation that’s previously failed. - Scheduler Agent Supervisor
Coordinate a set of actions across a distributed set of services and other remote resources. - Sharding
Divide a data store into a set of horizontal partitions or shards. - Sidecar
Deploy components of an application into a separate process or container to provide isolation and encapsulation. - Static Content Hosting
Deploy static content to a cloud-based storage service that can deliver them directly to the client. - Strangler
Incrementally migrate a legacy system by gradually replacing specific pieces of functionality with new applications and services. - Throttling
Control the consumption of resources used by an instance of an application, an individual tenant, or an entire service. - Valet Key
Use a token or key that provides clients with restricted direct access to a specific resource or service.
知っておくと、アーキを考えるときに役立つと思います。
まとめ
デザパタのドキュメントは、一度読んで全部覚えるというよりも、たまに読み返してみると、ここもっとこうした方がよかったなーっていう気づきが自分はあります。
それは、自分の設計スキルが低いからなのかもしれないですが。。。
ただ、このデザインパターンを Microsoft Azure 上でシステム構築をする時のデザインパターンではなく、Microsoft Azure 上で動くアプリケーションのデザインパターンであることは注意が必要です。
たとえば、このデザインパターンをうまく使って Web アプリを開発したとします。
それが、オンプレミスから接続される社内システムでも、インターネット越しにアクセスのあるコンシューマーシステムでも、アプリケーションを動かすという部分は一緒です。
でも、認証どうするとか、WAFどうするとかプライベートネットワークに閉じるとか、そういった部分はこのデザインパターンには含まれてません。
この部分を理解せずに、デザインパターンを読むとちょっと違った論点になるかもしれないので注意が必要です。
でも、Azure を使う上でのデザインパターンって需要あるもんなのかなー。
サービスがどんどん変わるし、それにあわせてデザインは変わっちゃうから、あってもあまり意味ないと思うんだよな～。
コメント