Microservice and agile development
•Download as PPTX, PDF•
1 like•1,379 views
2020/06/29 マイクロサービスアーキテクチャとアジャイル開発
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Microservice and agile development
Similar to Microservice and agile development (20)
More from Kameda Harunobu
Microservice and agile development
- 1. © 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved. ～マイクロサービスアーキテクチャとアジャイル開発 2020.06.25 Amazon Web Services Japan K.K. Senior Dev.Advocate Harunobu Kameda
- 2. AWS の基本コンセプト 必要な時に、必要なだけ、低価格で 使用分のみ支払い 初期投資不要 低額の変動費 開発者は作業を阻害しない ITインフラが必要 API経由で操作可能な コンピュートリソースプール
- 6. Infrastructure as Code (IaC) • リソースはAPI経由でプロビジョニング • 定義ファイルによる、効率化と自動化 • エラーやセキュリテイ違反の除去 https://ja.wikipedia.org/wiki/Infrastructure_as_Code Cloud Computing • 大規模化、共有リソースプールによる効率化 • データセンター、ネットワーク、ハードウェアの抽象化 • 多くのマネージドサービス
- 7. 190を超えるサービス – Building Block
- 11. © 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. スピードと俊敏性に こだわるための小規模 チーム Two-Pizza Teams 小さくそれぞれ が自律的に動け る組織 何を作るかから 実行までのすべ ての権限を持つ 主体性 と 自立性 を 重視
- 12. © 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 実験 は早めに、頻繁に
- 13. © 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved. AWS が提供するソリューションの数々 コンピューティング 開発者用ツール 機械学習 ビジネスの 生産性 ストレージ 管理ツール モバイルサービス デスクトップと アプリケーションの ストリーミング データベース メディアサービス AR（拡張現実）と VR（バーチャルリアリティ） IoT マイグレーション セキュリティ アクセス権管理、法令遵守 アプリケーション 構築 ゲーム開発 ネットワーク & コンテンツ配信 分 析 カスタマー エンゲージメント ブロックチェーン ロボット工学 人工衛星 190+
- 15. Microservice化とその成果 = 6700万回/年のデプロイ 数千のチーム × Microservices × 継続的デリバリ × 複数の環境
- 18. releasetestbuild releasetestbuild releasetestbuild releasetestbuild releasetestbuild releasetestbuild Microservices Deploy Model + IaC 開発者 デリバリパイプラインサービス
- 19. LB 共有 データソース Blue / Green Deployment DNS Application v1 WEB APP Application v2 WEB APP Snapshot
- 20. @2018, Amazon Web Services, Inc. or its Affiliates. All rights Reserved What is Cloud Native ? リソースは伸縮可能 API 経由で操作 セッションをお腹に持たない べき等性 Restful, Stateless CI/CD サーバレス コンテナ
- 21. @2018, Amazon Web Services, Inc. or its Affiliates. All rights Reserved クラウドネイティブ開発だから アジャイルでOK アジャイルだから ドキュメントは 後回しでいこう
- 22. @2018, Amazon Web Services, Inc. or its Affiliates. All rights Reserved プロセスやツールよりも個人と対話を 包括的なドキュメントよりも動くソフトウェアを 契約交渉よりも顧客との協調を 計画に従うことよりも変化への対応を アジャイルソフトウェア開発宣言
- 23. @2018, Amazon Web Services, Inc. or its Affiliates. All rights Reserved 顧客へ提供しうる価値の最大化 アジャイルソフトウェアとクラウド 【価値の最大化】のみを目的とし Legacy手法の変更を行う
- 24. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T Microservice/アジャイル開発とドキュメンテーション
- 25. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T マイクロサービスとAPI 疎結合なAPI連携のみで有機的に結合 APIへの改修、新規APIリリースは最大限の注意が必要 改修 リリース リリース ドキュメンテーション＆レビュー 非改修 （ソース = ドキュメント ?)
- 26. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T と、いうことは・・・？ つまり
- 27. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T と、いうことは・・・？ つまり
- 28. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T と、いうことは・・・？ つまり
- 29. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T と、いうことは・・・？ つまり
- 30. NITROSERVER Management, security, and monitoring Network Storage Nitro Hypervisor Nitro Controller C5
- 31. Virtualization
- 32. Classic virtualization S E R V E R C U S T O M E R I N S T A N C E S X E N H Y P E R V I S O R VPC NETWORKING EBS STORAGE LOCAL STORAGE MANAGEMENT SECURITY + MONITORING Dom0
- 33. Classic virtualization S E R V E R COMPLEXITY, OVERHEAD, VIRTUALIZATION TAX C U S T O M E R I N S T A N C E S X E N H Y P E R V I S O R VPC NETWORKING EBS STORAGE LOCAL STORAGE MANAGEMENT SECURITY + MONITORING Dom0
- 35. API
- 37. S E R V E R C U S T O M E R I N S T A N C E S X E N H Y P E R V I S O R VPC NETWORKING EBS STORAGE LOCAL STORAGE MANAGEMENT SECURITY + MONITORING Dom0 Classic virtualization
- 38. N I T R O C U S T O M E R I N S T A N C E S X E N H Y P E R V I S O R VPC NETWORKING EBS STORAGE LOCAL STORAGE MANAGEMENT SECURITY + MONITORING Dom0 S E R V E R P C I e B U S Nitro: Step 1 C3 インスタンス
- 39. N I T R O P C I e B U S C U S T O M E R I N S T A N C E S X E N H Y P E R V I S O R VPC NETWORKING EBS STORAGE LOCAL STORAGE MANAGEMENT SECURITY + MONITORING Dom0 S E R V E R Nitro: Step 2 C4 インスタンス
- 40. N I T R O P C I e B U S C U S T O M E R I N S T A N C E S X E N H Y P E R V I S O R VPC NETWORKING EBS STORAGE LOCAL STORAGE MANAGEMENT SECURITY + MONITORING Dom0 S E R V E R Nitro: Step 3
- 41. N I T R O H Y P E R V I S O R N I T R O P C I e B U S C U S T O M E R I N S T A N C E S VPC NETWORKING EBS STORAGE LOCAL STORAGE MANAGEMENT SECURITY + MONITORING Nitro: S E R V E R μEMU etc. Step 4 ENA C5 インスタンス
- 42. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. API マイクロサービス イベント API マイクロサービス モバイル クライアント クライアント IoT マイクロサービスとイベントドリブン Serverless Computing
- 43. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS のサービスを活用した疎結合の例 ３階層構造 ウェブサーバーはアプリサーバーと密結合 Web Server App Server ELB を挟んで疎結合に Web Server App Server ELB ELB は、 Auto Scaling を 組み合わせ、増減する App Server を自動で 登録/解除可能 Web Server は単一の ELB の DNS 名だけを 見てれば良い (App Server は Web Server にとってブラッ クボックス) スケールアウト/インするた びに、Web Server の設定 ファイルの書き換えが必要
- 44. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS のサービスを活用した非同期処理の例 Amazon SQS を挟んで Frontend と Backend を非同期かつ疎結合に BackendもQueueの滞留に合わせてオートスケール Frontend Servers ELB Client 重たい処理は Backend Servers に任せる Sticky Session Backend Servers SQS キューから取得した メッセージを元にバッチ的 に処理を実行していく 重たい処理は Backend で 非同期に行われるので、 Client へのレスポンスは迅 速に Amazon SQS Queue
- 45. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 単純なECサイトのシーケンス クライアント WEB DB
- 46. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 非同期処理なECサイトのシーケンス クライアント WEB DB App SQS
- 47. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. リアルタイムのレスポンスを要求しないシステム IoT センサーデバイス Amazon Kinesis
- 48. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. お客様事例：あきんどスシロー様 捨てていたデータをクラウドに送り、他のデータと合わせて分析することで、 今まで見えなかったことがデータとして可視化に成功。
- 49. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. データベースの選択 • AWS では多様な データベースの選択肢 • ワークロードに応じて 最適な選択が可能 Purpose built The right tool for the right job https://www.allthingsdistributed.com/2018/06/purpose-built-databases-in-aws.html 適材適所の選択
- 50. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. データの種類に応じて適切なデータストアを選択 サーバー ローカル ストレージ サーバー ローカル ストレージ 共有 ストレージ データベース (RDBMS) データベース (NoSQL) ・ショッピングカート ・セッション情報 ・ユーザ情報 ・商品情報 ・在庫情報 ・商品画像データ 複数データストアの使い分けで効率を向上 “A one size fits all database doesn't fit anyone”
- 51. VPC Public subnet Availability Zone Private subnet 一般的なWEBサービスの構成図 2階層構造 VPC Public subnet Availability Zone Availability Zone Private subnet ELB EC2 ElastiCache RDS
- 52. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 従来のエンタープライズ DB システム アプリ オンライン トランザクション ETLツール 分析 BIツールOLTP DB OLAP DB
- 53. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 万能のデータベース は存在しない “A one size fits all database doesn't fit anyone” Werner Vogels CTO - Amazon.com
- 54. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. A m a z o n D y n a m o D B キ ー バ リ ュ ー イ ン メ モ リ グ ラ フリ レ ー シ ョ ナ ル A m a z o n R D S A m a z o n Q L D B 元 帳時 系 列 A m a z o n T i m e s t r e a m A m a z o n A u r o r a A m a z o n D o c u m e n t D B ド キ ュ メ ン ト A m a z o n N e p t u n e A m a z o n E l a s t i C a c h e A m a z o n R D S f o r V M W a r e E l a s t i C a c h e f o r R e d i s E l a s t i C a c h e f o r M e m c a c h e d A m a z o n R e d s h i f t デ ー タ ウ ェ ア ハ ウ ス 移 行 AWS Database Migration Service ワークロードに適した最適なデータベース選択 A m a z o n M a n a g e d A p a c h e C a s s a n d r a S e r v i c e ( M C S )
- 55. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T
Editor's Notes
- このセッションではアマゾンのイノベーションに関する話を共有させていただきます。 AWSではEBCというファシリティを設けてお客様に様々な情報のご提供を差し上げていますが、一番人気であるのが、Amazonの文化に対するセッションです。 本日お届けするのは飽くまでもAmazonにおけるイノベーションの考え方や実行の話で、全てのお客様にこのやり方が合うとは思いませんが、皆様の会社におけるイノベーション展開の一助になればと幸いです。
- その考え方をもとにクラウドコンピューティングは誕生しました。 その基本的なコンセプトのおさらいがこちらです。 AWSは、初期費用が無償であり、低額な、従量課金です。必要な時に必要なだけITリソースを利用することができ、長期の契約は不要です。 このサービスの提供形態は、カスタマーの使い勝手を向上させ、そしてAWSが常にカスタマーに満足してもらう必要があることに繋がります。
- 1つ目がアーキテクチャの変更です。 モノリシックアーキテクチャをやめ、SOAサービス指向アーキテクチャへ移行します。 機能単位の小さなサービスに分割しました。 例えば、製品ページの購入ボタンと、税金を計算するサービスのようにです。 全てのサービスはWebサービスとしてパッケージ化して、HTTPのインターフェースを持ちます。 そして、これらのサービスは相互にHTTPのインターフェースを通じて通信します。 これは2009年、6年ほど前のことです。 左の図はアーキテクチャを図示したものです。 これはいわゆる最近だとMicroservicesと呼ばれるムーブメントになっています。 - we took the monolith and broke it apart into a service oriented architecture - factored the app into small, focused, single-purpose services, which we call "primitives" - for example, we had a primitive for displaying the buy button on a product page, and we had one for calculating taxes - every primitive was packaged as a standalone web service, and got an HTTP interface - these building blocks only communicated to each other through the web service interfaces - to give you an idea of the scope of these small services, I've included this graphic - this is the constellation of services that deliver the Amazon.com website back in 2009, 6 years ago - this term didn't exist back then, but today you'd call this a microservice architecture Moving to a SOA - everything gets a service interface - breaking monolithic app into small services (primitives) - picture of what amazon.com looked like after this transformation (actual depiction of our service architecture) - today, I guess it’s popular to call this “microservices”
- モノリシックアーキテクチャーは、その規模の拡大とともに、いろいろな問題を生じさせます。 まず、中身が複雑となりその全体像を把握することが困難となります。 そして新しいモジュールの投入や機能改善が、システムの他の部分に及ぼす影響を把握しずらくなり、 物理的限界を超えていきます。このため、ビルドやテストに時間がかかり、予期しない問題を引き起こし デグレードなどが発生しやすくなります。このため、デプロイ作業で問題が発生することも増加します。 さらに重要なことは、モノリシックなアーキテクチャは基本的にスケールアップにしか対応できず、スケーラビリティに限界が来ることです。
- We have a distinctly Amazonian way of organizing to optimize execution. We’re structured organizationally to try and enable agility. And one of the ways we’ve done that is what we call our ‘two-pizza teams. --meaning that no team should be big enough that it would take more than two pizzas to feed them. The fundamental concept of the two-pizza team came out of efforts to minimize the need for communications, minimize time in unnecessary meetings, and accelerate the decision making process. While we can debate around the size of the pizza, this concept is fundamentally around creating a little startup of around 5-10 people. Providing the conditions so that each team has ownership and autonomy, and provide deep focus in one area. These decentralized, autonomous teams are empowered to develop and launch based on what they learn from interactions with customers. Why do we do this? We found there is an exponential function in the overhead of communication with the more people you add on a team. And once you get to 11 or 12 is when you hit that exponential rate. You add more people, more people means more communication, that slows things down. So a 2PT has the resources embedded in them to have full ownership. So they own every function from engineering, to testing, to product management – and we try to embed all those resources on that single team and make them single-threaded, with a single owner, and give them a very tight charter and mission to they can run as fast as possible and have focus in one area. [Single threaded leaders] So 2PT push ownership, push autonomy. You build the software, you test the software, you operate, you think about the future of it. Btw, this also has an impact on code quality. If you’re responsible for maintaining, and you’ll get paged on a sat. night if your software breaks, you’ll probably do a better job building it in the first place. As demands grow and the team needs to expand, we split teams into separate 2-pizza teams working on sub—areas, rather than simply make the team bigger. This concept of a 2PT has been around for many years, and culture at the individual team level has changed very little, because it’s self-reinforcing and it’s one of the things we’ve done that’s helped us scale dramatically over time.
- Enable experimentation via primitives Build on existing services Lower the costs of failure Prototype, iterate – a LOT Embrace failure as learning
- マイクロサービスで構成されたアプリケーションの概要図がこちらです。 お互いのコンポーネントは疎結合状態を保ち、独立したアプリケーションとして存在します。 そしてそれらの通信経路はAPIのみとすることで非同期な開発、バージョンアップを可能とします。 この際、各コンポーネント間の連携経路をリアルタイム型ではなく、イベント駆動型にすることで より独立した開発を可能とします。 リアルタイム連携の場合、常にお互いの同期がとれた状態である必要がありますが。 イベント駆動型の場合、指示を出すタミングのみ連携すればよく、分割した管理をよりやりやすくなります。
- そうして、2014年時点で、数千のチームがこのアーキテクチャを採用し、 継続的デリバリを個別に行いながら、複数の環境を維持し、年間5000万回のデプロイを実現しています。 この開発手法は、AWSそのものにも取り入れられており、 2017年では1430回の機能改善を実現しています。 そして複数のチームが独立した開発を行っています。
- 30
- So let’s start at one of the most fundamental layers in the cloud – Virtualization. Virtualization is one of the major technical underpinnings that have enabled cloud computing to become what it is today.
- Most people here probably have a reasonable understanding of what Virtualization and Virtual Machines are, but let’s talk about it at the most fundamental level – The hypervisor. A hypervisor is a piece of system software that provides virtual machines (VMs), which users can use to run their OS and applications on. The hypervisor provides isolation between VMs, which run independent of each other, and also allows different VMs to run their own OS. Like other virtualization techniques, hypervisors provide multitenancy, which simplifies machine provision and administration. Hypervisors have been around for a very long time, going back to the late 60’s. In the late 90’s, the x86 based VMware hypervisor was released. This is when virtualization really began to go mainstream. It used binary translation to replace privileged instructions to trap into the hypervisor, while still running unprivileged instructions directly on the physical CPU, which solved x86’s virtualization issues (Adams and Agesen, 2006). This allowed the VMware hypervisor to run unmodified commodity OS’es on x86 hardware in virtual machines without the performance penalty of emulation. The Xen hypervisor released first in 2003 took a different approach to solving the x86 virtualization issue. Instead of binary translation, they modified the source code of the guest OS to trap to the hypervisor instead of executing non-trapping privileged instructions.
- Virtualization had significant impact on the IT industry, and allowed for systems administrators optimize resource utilization and use new availability techniques to improve uptime. With AWS, we have pushed the boundaries of what traditional virtualization can provide. As we’ve further optimized resource utilization we reached a point where the root virtualization IO tax (hardware on the boards, shared between all guests) – is something that has become a very real limitation. We need to create an environment where customers don’t see network jitter and these other virtualization challenges impacting their workloads.
- Just like with any monolithic app there were too many interconnected systems in the virtualization stack. This is one of the reasons why we found the need to rethink/refactor. In recent years we’ve seen a shift from monolithic architecture and design, to SoA and Microservices.
- As you look at this, you see how closely tied to the hardware this is, and you start to think of this as a distributed system. What lessons can we take from purpose built IoT devices, and build a system of independent controllers/devices connected together via an API?
- This is why we built Nitro. Nitro gives us modular, software programmable, virtualizable infrastructure. The modularity lets us recompose the infrastructure resources into different shape
- Let’s talk about how we actually built this. As we mentioned, traditional virtualization has limitations in the complex orchestration and virtualization traps that happen at the hypervisor level. A crucial observation here was that to deliver this experience, we need to vastly reduce the number of traps hypervisors take and replace software with hardware acceleration.
- Step 1: When we started building Nitro several years ago, we started by tackling networking and asking how we could eliminate those hundreds of thousands of traps required to download a file from S3. Our answer to this was our very first Nitro offload card which we launched at re:Invent 2013 in the C3 instance type, a full six years ago. We learned a lot building the first Nitro card. It took us multiple years including restarting the software stack at least twice. A really critical thing we learned is that when using hardware offloads like Nitro, we needed to build the software from the start to take advantage of the underlying hardware. {Internal note} This was not ENA at this point. Intel NIC.
- Step 2: The first Nitro card was great and customers loved the improved performance and consistency that came in C3 but we wanted to do more and were hitting the limits of off the shelf hardware. Fortunately, we began working with a startup called Annapurna Labs and launched our second generation of Nitro card in the C4 instance type. Instead of just offloading networking, we were also able to offload EBS storage delivering higher performance and better consistency.
- Step 3: We had such great success with the Nitro card in C4 that had Annapurna Labs join AWS and we began working on our next big jump in Nitro technology which we launched with C5. For C5, we offloaded all I/O operations including networking, EBS storage, and local storage.
- Step 4: This is one of the most significant iterations yet, where we introduce the Nitro hypervisor for the first time. The Nitro hypervisor allows us to remove the Dom0 from the stack, where we take all of these management overhead capabilities, such as providing DNS, instance metadata and other things that the system board needs to interact with in order to boot (mouse/keyboard emulation, etc.) and move this off to an off-board Nitro controller. Here we also really introduced the first unified system for the elastic Network adapter, where it’s not a traditional NIC any more, but software running on an acclererated Nitro card and is one of the first things we co-built with Annupurna on the X1 instance type. https://aws.amazon.com/about-aws/whats-new/2016/06/introducing-elastic-network-adapter-ena-the-next-generation-network-interface-for-ec2-instances/
- マイクロサービスで構成されたアプリケーションの概要図がこちらです。 お互いのコンポーネントは疎結合状態を保ち、独立したアプリケーションとして存在します。 そしてそれらの通信経路はAPIのみとすることで非同期な開発、バージョンアップを可能とします。 この際、各コンポーネント間の連携経路をリアルタイム型ではなく、イベント駆動型にすることで より独立した開発を可能とします。 リアルタイム連携の場合、常にお互いの同期がとれた状態である必要がありますが。 イベント駆動型の場合、指示を出すタミングのみ連携すればよく、分割した管理をよりやりやすくなります。
- Loose Coupling As application complexity increases, a desirable attribute of an IT system is that it can be broken into smaller, loosely coupled components. This means that IT systems should be designed in a way that reduces interdependencies—a change or a failure in one component should not cascade to other components. 従来のインフラストラクチャでは、それぞれが特定の目的を備えた、一連の緊密に統合されたサーバーが中心となっていました。しかし、これらのコンポーネントやレイヤーの一つが停止すると、最終的にはシステムに致命的な中断が発生する場合があります。さらに、スケーリングも阻害されます。1 つのレイヤーにサーバーを追加または削除すると、それに接続していたすべてのレイヤーの全サーバーも適切に接続される必要があります。 疎結合により、可能な場合は、管理されたソリューションをシステムのレイヤー間の中間証明書として活用できます。これにより、コンポーネントやレイヤーの障害およびスケーリングが、この媒介である疎結合によって自動的に処理されます。 コンポーネントを非干渉化するための 2 大ソリューションは、ロードバランサーとメッセージキューです。
- Asynchronous Integration Asynchronous integration is another form of loose coupling between services. This model is suitable for any interaction that does not need an immediate response and where an acknowledgement that a request has been registered will suffice. It involves one component that generates events and another that consumes them. The two components do not integrate through direct point-to- point interaction but usually through an intermediate durable storage layer (e.g., an Amazon SQS queue or a streaming data platform like Amazon Kinesis). This approach decouples the two components and introduces additional resiliency. So, for example, if a process that is reading messages from the queue fails, messages can still be added to the queue to be processed when the system recovers. It also allows you to protect a less scalable back end service from front end spikes and find the right tradeoff between cost and processing lag. For example, you can decide that you don’t need to scale your database to accommodate for an occasional peak of write queries as long as you eventually process those queries asynchronously with some delay. Finally, by moving slow operations off of interactive request paths you can also improve the end-user experience.
- Asynchronous Integration Asynchronous integration is another form of loose coupling between services. This model is suitable for any interaction that does not need an immediate response and where an acknowledgement that a request has been registered will suffice. It involves one component that generates events and another that consumes them. The two components do not integrate through direct point-to- point interaction but usually through an intermediate durable storage layer (e.g., an Amazon SQS queue or a streaming data platform like Amazon Kinesis). This approach decouples the two components and introduces additional resiliency. So, for example, if a process that is reading messages from the queue fails, messages can still be added to the queue to be processed when the system recovers. It also allows you to protect a less scalable back end service from front end spikes and find the right tradeoff between cost and processing lag. For example, you can decide that you don’t need to scale your database to accommodate for an occasional peak of write queries as long as you eventually process those queries asynchronously with some delay. Finally, by moving slow operations off of interactive request paths you can also improve the end-user experience.
- Asynchronous Integration Asynchronous integration is another form of loose coupling between services. This model is suitable for any interaction that does not need an immediate response and where an acknowledgement that a request has been registered will suffice. It involves one component that generates events and another that consumes them. The two components do not integrate through direct point-to- point interaction but usually through an intermediate durable storage layer (e.g., an Amazon SQS queue or a streaming data platform like Amazon Kinesis). This approach decouples the two components and introduces additional resiliency. So, for example, if a process that is reading messages from the queue fails, messages can still be added to the queue to be processed when the system recovers. It also allows you to protect a less scalable back end service from front end spikes and find the right tradeoff between cost and processing lag. For example, you can decide that you don’t need to scale your database to accommodate for an occasional peak of write queries as long as you eventually process those queries asynchronously with some delay. Finally, by moving slow operations off of interactive request paths you can also improve the end-user experience.
- Asynchronous Integration Asynchronous integration is another form of loose coupling between services. This model is suitable for any interaction that does not need an immediate response and where an acknowledgement that a request has been registered will suffice. It involves one component that generates events and another that consumes them. The two components do not integrate through direct point-to- point interaction but usually through an intermediate durable storage layer (e.g., an Amazon SQS queue or a streaming data platform like Amazon Kinesis). This approach decouples the two components and introduces additional resiliency. So, for example, if a process that is reading messages from the queue fails, messages can still be added to the queue to be processed when the system recovers. It also allows you to protect a less scalable back end service from front end spikes and find the right tradeoff between cost and processing lag. For example, you can decide that you don’t need to scale your database to accommodate for an occasional peak of write queries as long as you eventually process those queries asynchronously with some delay. Finally, by moving slow operations off of interactive request paths you can also improve the end-user experience.
- 商品の画像データのような、データサイズが比較的大きいデータは、データベースではなく、共有ストレージであるS3に保存しましょう。 では、ここからS3について説明していきます。