Azure Architecture Center

Azure

こんにちは。

最近仕事が忙しくて、ちょっと疲れているので、Azure Architecture Center で癒しを得ています。

ということで、癒されポイントをちょっと整理してみたいなって思いました。

ひとまず、Azure Architecture Center のドキュメントのリンクを貼っておきます。

Azure Architecture Center - Azure Architecture Center
The Azure Architecture Center provides guidance for designing and building solutions on Azure using established patterns...

 

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 の雑記の記事をご覧ください。

https://blog.engineer-memo.com/2019/05/11/azure-sql-database-serverless-%E3%83%97%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC-%E3%82%92%E8%A7%A6%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/

ちなみに、Azure SQL Database Serverless で、16vCoreを選べるようになったのは、最近みたいです。

Update to Azure SQL Database serverless increases compute scale limits by 4x | Azure updates | Microsoft Azure
We are now announcing the max vcore limit has increased by 4x to 16 vcores and provides greater compute scaling headroom...

 

Cloud Design Patterns

Queue-Based Load Leveling pattern について紹介しましたが、その他にも 全部で34 種類のデザインパターンが、Azure Architecture Center 以下のドキュメントで紹介されています。

Cloud design patterns - Azure Architecture Center
Learn about design patterns for building reliable, scalable, secure applications in the cloud by walking through example...

※ 英語苦手な人は、↑のリンクの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 を使う上でのデザインパターンって需要あるもんなのかなー。

サービスがどんどん変わるし、それにあわせてデザインは変わっちゃうから、あってもあまり意味ないと思うんだよな~。

コメント

タイトルとURLをコピーしました