Global Azure Bootcamp 2018@Tokyo Azure アーキテクチャ祭り Cloud Design Patterns編

1. Azure アーキテクチャー祭り
Cloud Design Patterns 編
Takekazu Omi
takekazu.omi@kyrt.in
2018/4/21 R1.0.0

2. Azure Architecture Center
https://docs.microsoft.com/ja-jp/azure/architecture/
2018/4/20 kyrt inc 2

3. Azure Architecture Center
kyrt inc 32018/4/20
Azure Application Architecture Guide
顧客とのエンゲージメントから学んだ実証済みのプラクティスに基づ
いた、スケーラブル、レジデント、可用性の高いアプリケーションを設
計するためのガイド
Azure Reference Architectures
Azureで推薦されるアーキテクチャセット。各アーキテクチャには、ベ
ストプラクティス、規範的な手順、展開可能なソリューションを提示
https://github.com/mspnp/reference-architectures
Cloud Design Patterns
クラウド内の信頼性の高いスケーラブルで安全なアプリケーションを
構築のためのデザインパターン集 +8 = 32

4. Cloud Design Patterns
クラウド設計パターン
2018/4/20 kyrt inc 4

5. 2014年6月
 Microsoft patterns & practices
 Cloud Design Patterns: Prescriptive
Architecture Guidance for Cloud
Applications
 http://msdn.microsoft.com/en-
us/library/dn568099.aspx
 翻訳が、2014年6月に出ました
 クラウドデザインパターン Azureを例としたク
ラウドアプリケーション設計の手引き
 http://ec.nikkeibp.co.jp/item/books/P98330.html
 日経BP
kyrt inc 52018/4/20

6. 概要
クラウドアプリケーション設計の頻出課題集
Software design pattern の Cloud Application 版
24のパターン
10のガイダンス
ポスター
 http://azure.microsoft.com/en-
us/documentation/infographics/cloud-design-patterns/
kyrt inc 62018/4/20

7. kyrt inc 72018/4/20
2018年4月現在

8. ３２パターン、８つのChallenge
 信頼性の高い、スケーラブルで安全なアプリケー
ションの構築
 問題、適用に関する考慮事項、 Azure に基づいた
例を説明
 幾つかのパターンには、Azure 上の実装コード サン
プルを含む
 パターンのほとんどは、クラウド プラットフォームに
非依存
kyrt inc 82018/4/20
https://docs.microsoft.com/ja-jp/azure/architecture/patterns/

9. ８つのChallenge
Challengeを課題と訳すと超えがたい問題という風に感じませんか
2018/4/20 kyrt inc 9

10. とりあえず表にした
kyrt inc 102018/4/20

11. 名前 内容
1 Availability 可用性
アプリケーションの可用性が最大限になるように設計および実装する。可用性は、システム エラー、インフラストラ
クチャの問題、悪意ある攻撃、およびシステムの負荷によって影響を受ける。
2 Data Management データ管理
データ管理は重要な要素であり品質属性のほとんどに影響する。 通常、パフォーマンス、スケーラビリティ、また
は可用性の理由から、データは複数のサーバーにまたがって保存されるが、これによって、様々な問題が発生す
る。データの分散配置は整合性と同期の必要性を生じさせる。
3
Design and
Implementation
設計と実装
コンポーネントの設計とデプロイの一貫性や統一性、管理と開発を簡素化する保守容易性、コンポーネントやサ
ブシステムを他のアプリケーションやシナリオで利用できる再利用性は、アプリケーションやサービスの品質と総
保有コストに大きな影響を及ぼす
4 Messaging メッセージング
クラウド アプリケーションのスケーラビリティでは、コンポーネントとサービスが 疎結合的に接続できるメッセージ
ング インフラストラクチャが重要です。 非同期メッセージングには多くの利点がありますが、メッセージの順序、有
害メッセージの管理、べき等など、課題も多くある。
5
Management and
Monitoring
管理と監視
クラウド アプリケーションは、リモートのデータセンターで実行され、自分でそのインフラストラクチャや、オペレー
ティング システムを、完全に制御することはできないため、オンプレミス よりも管理と監視は難しくなる。 アプリ
ケーションは、管理と監視に使用できる情報を公開する必要がある。
6
Performance and
Scalability
パフォーマンスとス
ケーラビリティ
パフォーマンスは、規定の期間内に任意の処理を実行するシステムの応答性を示し、スケーラビリティは、パ
フォーマンスに影響を与えずに負荷の増加を処理するか、または利用可能なリソースを容易に増やすことで対応
する能力である。 通常ワークロードやアクティビティのピークは変動しており、予測することは困難。（特にマルチ
テナント シナリオでは）このような環境では、アプリケーションは、要求に対応できるように制限範囲内でスケール
アウト、スケールインできることが要求される。
7 Resiliency 回復性
回復性とは、障害を正常に処理して復旧するシステムの機能。 クラウド ホスティングでは、マルチテナントのアプ
リケーションが多い、共有プラットフォームを使用する、リソースと帯域幅が競合する、インターネットで通信する、
コモディティ ハードウェア上で実行する、という特性がある。これらの特性は、一時的な障害と永続的な障害の両
方が発生しやすくなることを意味する。そのため 迅速かつ効率的に障害を検出して復旧することが、回復性を維
持する上で重要となる。
8 Security セキュリティ
セキュリティとは、設計された用途以外の悪意あるアクションや偶発的なアクションを防ぎ、情報の漏えいや損失
を防ぐシステムの機能。アプリケーションの設計とデプロイでは、悪意のある攻撃から保護し、承認したユーザー
のみにアクセスを制限し、機密データを保護する必要がある。
kyrt inc 112018/4/20

12. Availability -可用性
 システムが機能し動作している時間の割合
 稼働時間の比率として計測
 システム エラー、インフラストラクチャの問題、悪意ある攻撃、
およびシステムの負荷によって影響を受ける
 最大限になるように設計および実装する
 システム エラー、インフラストラクチャの問題、悪意ある攻撃、
およびシステムの負荷に影響される
kyrt inc 122018/4/20
https://docs.microsoft.com/ja-jp/azure/architecture/patterns/category/availability

13. Data Management -データ管理
 データ管理はクラウド アプリケーションの重要な要
素で、品質属性のほとんどに影響
 パフォーマンス、スケーラビリティ、または可用性の
要件から、データは分散してホストされる
 分散は、整合性の維持、同期の問題を生む
kyrt inc 132018/4/20
https://docs.microsoft.com/ja-jp/azure/architecture/patterns/category/data-management

14. Design and Implementation
-設計と実装
 設計要素
 コンポーネントの設計
 デプロイの一貫性、統一性
 管理および開発を容易にする保守性
 他のアプリケーションやシナリオでの再使用可能性
 設計および実装フェーズは、品質と総保有コストに大き
な影響がある
kyrt inc 142018/4/20
https://docs.microsoft.com/ja-jp/azure/architecture/patterns/category/design-implementation

15. Messaging -メッセージング
スケーラビリティでは、コンポーネントとサービ
スの疎結合にメッセージング インフラが重要
非同期メッセージングには多くの利点がある
が、メッセージの順序、有害メッセージの管理、
べき等など、課題も多い
kyrt inc 152018/4/20
https://docs.microsoft.com/ja-jp/azure/architecture/patterns/category/messaging

16. Management and Monitoring
-管理と監視
 クラウド アプリケーションは、リモートのデータセン
ターで実行
 インフラストラクチャや、オペレーティング システム
の制御は制限され、オンプレミス よりも管理と監視
は難しくなる
 アプリケーションも、管理と監視に使用できる情報を
公開する必要がある
kyrt inc 162018/4/20
https://docs.microsoft.com/ja-jp/azure/architecture/patterns/category/management-monitoring

17. Performance and Scalability
-パフォーマンスとスケーラビリティ
 パフォーマンスは、規定の期間内に任意の処理を実行する応答性
 スケーラビリティは、パフォーマンスに影響を与えずに負荷の増加
を処理、または利用可能なリソースを容易に増やすことで対応す
る能力
 通常ワークロードやアクティビティのピークは変動し、予測すること
は困難（マルチテナント シナリオ）
 アプリケーションは、要件に対応できるように制限範囲内でスケー
ルアウト、スケールインが要求
kyrt inc 172018/4/20
https://docs.microsoft.com/ja-jp/azure/architecture/patterns/category/performance-scalability

18. Resiliency - 回復性
 回復性とは、障害を正常に処理して復旧する機能
 クラウド ホスティングの特性
 マルチテナントのアプリケーションが多く共有プラットフォームを使用
 リソースと帯域幅が競合
 インターネットで通信
 コモディティ ハードウェア上での実行
 これらの特性は、一時的な障害と永続的な障害の両方が発
生しやすくなることを意味する
 迅速かつ効率的に障害を検出して復旧することが、回復性
を維持する上で重要
kyrt inc 182018/4/20
https://docs.microsoft.com/ja-jp/azure/architecture/patterns/category/resiliency

19. Security -セキュリティ
 セキュリティとは、設計された用途以外の悪意ある
アクションや偶発的なアクションを防ぎ、情報の漏え
いや損失を防ぐシステムの機能
 アプリケーションの設計とデプロイでは、悪意のある
攻撃から保護し、承認したユーザーのみにアクセス
を制限し、機密データを保護する必要がある
kyrt inc 192018/4/20
https://docs.microsoft.com/ja-jp/azure/architecture/patterns/category/security

20. Patternsと８つのChallenge
PatternとChallengeの表
2018/4/20 kyrt inc 20

21. とりあえず表にした
kyrt inc 212018/4/20

22. No Pattern Availability
Data
Manageme
nt
Design and
Implementa
tion
Messaging
Manageme
nt and
Monitoring
Performanc
e and
Scalability
Resiliency Security
1 Ambassador アンバサダー ◯ ◯
2
Anti-Corruption
Layer
破損対策レイヤー ◯ ◯
3
Backends for
Frontends
フロント エンド用
バックエンド
◯
4 Bulkhead バルクヘッド ◯
5 Cache-Aside キャッシュ アサイド ◯ ◯
6 Circuit Breaker
サーキット ブレー
カー
◯
7
Compensating
Transaction
補正トランザクション ◯
8
Competing
Consumers
競合コンシューマー ◯
kyrt inc 222018/4/20

23. No Pattern Availability
Data
Manageme
nt
Design and
Implementa
tion
Messaging
Manageme
nt and
Monitoring
Performanc
e and
Scalability
Resiliency Security
9
Compute Resource
Consolidation
コンピューティン
グ リソース統合
◯
10 CQRS
コマンド クエリ責
務分離 (CQRS)
◯ ◯ ◯
11 Event Sourcing
イベント ソーシン
グ
◯ ◯
12
External
Configuration Store
外部構成ストア ◯ ◯
13 Federated Identity
フェデレーション
ID
◯
14 Gatekeeper ゲートキーパー ◯
15
Gateway
Aggregation
ゲートウェイ集約 ◯ ◯
16 Gateway Offloading
ゲートウェイ オフ
ロード
◯ ◯
kyrt inc 232018/4/20

24. No Pattern Availability
Data
Manageme
nt
Design and
Implementa
tion
Messaging
Manageme
nt and
Monitoring
Performanc
e and
Scalability
Resiliency Security
17 Gateway Routing
ゲートウェイ ルー
ティング
◯ ◯
18
Health Endpoint
Monitoring
正常性エンドポイント
の監視
◯ ◯ ◯
19 Index Table
インデックス テーブ
ル
◯ ◯
20 Leader Election リーダー選定 ◯
21
Materialized
View
具体化されたビュー ◯ ◯
22 Pipes and Filters パイプとフィルターの ◯ ◯
23 Priority Queue Priority Queue ◯ ◯
24
Queue-Based
Load Leveling
キュー ベースの負荷
平準化
◯ ◯ ◯ ◯
kyrt inc 242018/4/20

25. No Pattern Availability
Data
Manageme
nt
Design and
Implementa
tion
Messaging
Manageme
nt and
Monitoring
Performanc
e and
Scalability
Resiliency Security
25 Retry 再試行 ◯
26
Scheduler Agent
Supervisor
Scheduler Agent
Supervisor
◯ ◯
27 Sharding シャーディング ◯ ◯
28 Sidecar サイドカー ◯ ◯
29
Static Content
Hosting
静的コンテンツ ホス
ティング
◯ ◯ ◯
30 Strangler ストラングラー ◯ ◯
31 Throttling 調整 ◯ ◯
32 Valet Key バレット キー ◯ ◯
kyrt inc 252018/4/20

26. Patterns
2018/4/20 kyrt inc 26

27. とりあえず表にした
ざっとみる
kyrt inc 272018/4/20

28. pattern 概要
1 Ambassador ◯
コンシューマーサービスまたはアプリケーションの代わりにネットワーク要求を送信するヘル
パーサービスを作成
2 Anti-corruption Layer ◯ 現代のアプリケーションと従来のシステムとの間にファサードまたはアダプタ層を実装
3 Backends for Frontends ◯
特定のフロントエンドアプリケーションまたはインタフェースで消費される個別のバックエンド
サービスを作成
4 Bulkhead ◯ アプリケーションの要素をプールに分離し、障害が発生した場合でも他の要素が機能を継続
5 Cache-Aside オンデマンドでデータをデータストアからキャッシュにロード
6 Circuit Breaker
リモートサービスまたはリソースに接続するときに修正するまでに多少の時間がかかる障害を
処理
7 Compensating Transaction 一連のステップによって実行された作業を元に戻すと、最終的に一貫した操作を定義
8 Competing Consumers 同じメッセージングチャネルで受信したメッセージを複数のコンカレントコンシューマで処理
kyrt inc 282018/4/20

29. pattern 概要
9
Command and Query Responsibility Segregation
(CQRS)
別のインターフェイスを使用してデータを更新する操作からデータを読み取る操作
を分離
10 Compute Resource Consolidation 複数のタスクまたは操作を1つの計算単位に統合
11 Event Sourcing
追加専用ストアを使用して、ドメイン内のデータに対するアクションを記述する一
連のイベントを記録
12 External Configuration Store アプリケーション展開パッケージから構成情報を一元的な場所に移動
13 Federated Identity 外部IDプロバイダへの認証を委任
14 Gatekeeper
クライアントとアプリケーションまたはサービス間のブローカとして機能する専用ホ
ストインスタンスを使用してアプリケーションとサービスを保護し、要求の検証とサ
ニタイズ、要求とデータの受け渡しを実施
15 Gateway Aggregation ◯ ゲートウェイを使用して、複数の個別の要求を1つの要求に集約
16 Gateway Offloading ◯ 共有または特殊なサービス機能をゲートウェイ・プロキシーにオフロード
kyrt inc 292018/4/20

30. pattern 概要
17 Gateway Routing ◯ 1つのエンドポイントを使用して複数のサービスに要求をルーティング
18 Health Endpoint Monitoring
外部ツールが公開されたエンドポイントを介して定期的にアクセスできるアプリ
ケーションで機能チェックを実装
19 Index Table クエリで頻繁に参照されるデータストア内のフィールドにインデックスを作成
20 Leader Election
1つのインスタンスをリーダーとして選択し、他のインスタンスを管理する責任を担
うことによって、分散アプリケーションの共同作業タスク・インスタンスの集合によっ
て実行されるアクションを調整
21 Materialized View
必要なクエリ操作のためにデータが理想的にフォーマットされていない場合、1つ
または複数のデータストア内のデータにあらかじめ作成されたビューを生成
22 Pipes and Filters 複雑な処理を実行するタスクを、再利用可能な一連の独立した要素に分割
23 Priority Queue
優先度の高い要求が優先度の低いものより速く受信され、処理されるように、
サービスに送信される要求に優先度を処理
24 Queue-Based Load Leveling
断続的な重い負荷を円滑にするために、タスクとそのサービスが呼び出すサービ
スの間のバッファーとして機能するキューを使用
kyrt inc 302018/4/20

31. pattern 概要
25 Retry
失敗した操作を透過的に再試行してサービスまたはネットワークリソースに接続、
予期した一時的な障害をアプリケーションが処理
26 Scheduler Agent Supervisor
分散した一連のサービスと他のリモートリソースにわたって一連のアクションを調
整
27 Sharding データストアを水平パーティションまたはシャードのセットに分割
28 Sidecar
アプリケーションのコンポーネントを別のプロセスまたはコンテナに配置し、分離と
カプセル化を提供
29 Static Content Hosting
静的コンテンツをクラウドベースのストレージサービスに展開します。クラウドベー
スのストレージサービスは、クライアントに直接配信
30 Strangler ◯
徐々に特定の機能を新しいアプリケーションやサービスに置き換えて、レガシーシ
ステムを段階的に移行
31 Throttling
アプリケーションのインスタンス、個々のテナント、またはサービス全体で使用され
るリソースの消費を制御
32 Valet Key
クライアントに特定のリソースまたはサービスへの直接アクセスが制限されている
トークンまたはキーを使用
kyrt inc 312018/4/20

32. 増えた８個を
掘り下げる
kyrt inc 322018/4/20

33. Ambassador - アンバサダー
 日本語で言うと、「大使」
 特命全権大使は、外交使節団の長で最上級の階級であ
る。接受国の元首に対して派遣され、外交交渉、全権代
表としての条約の調印・署名、滞在する自国民の保護な
どの任務を行う。国際連合などの国際機関の政府代表部
に対しても派遣される。（Wikipedia)
 代表して外部との交渉をおこなう
kyrt inc 332018/4/20
https://docs.microsoft.com/ja-jp/azure/architecture/patterns/ambassador

34. Ambassador - 概要
kyrt inc 342018/4/20
ネットワーク要求を送信す
るヘルパー サービス
監視、ログ記録、ルーティング、セキュリティ (TLS など)、回復性パ
ターン等の、クライアント接続のタスクをオフロードするのに有効
リトライ
サーキットブレーカー
モニター
セキュリティー

35. Ambassador - 問題と注意事項
 プロキシは待機時間のオーバーヘッドがある
 プロキシの汎用的な機能実装の影響を考慮
 再試行を処理する場合、すべての操作がべき等でない限り、それは安全で
はないかも
 クライアントがなんらかのコンテキスト情報をプロキシに渡す
 例：再試行を除外や、または再試行の最大回数を指定する HTTP 要求ヘッ
ダーや、プロキシでの再試行回数を返すレスポンスヘッダーなど
 プロキシのパッケージ化とデプロイ方法
 クライアントとプロキシのマッピング１：１にするかプロキシを共有にする
か等
kyrt inc 352018/4/20

36. Ambassador – 使い時
アプリケーションの変更に制限がある
レガシーアプリケーション
複数の言語が実装に使われている
通信のオーバーヘッドの影響が少ない
案件の対応チームが異なる
アプリチームでは無くインフラチームで対応など
kyrt inc 362018/4/20

37. Ambassador - 感想
単一言語で書かれていれば、ライブラリを共通
化し、アプリケーション内でインプロセスで実装
する方が問題が少ない
複数インスタンスを跨ってリモートサービスへの
アクセスを制限する必要がある場合は有用（接
続先のスロットリング要件が厳しい場合とか）
概念的な出番はよくあるパターンで重要
kyrt inc 372018/4/20

38. Anti-corruption Layer – 破損対策レイヤー
kyrt inc 382018/4/20
異なるサブシステム間にアダプター レイヤーを実装。サブシステム間の要
求を変換する。パターンを使用すると、アプリケーションの設計の外部サブ
システムへの依存関係が緩和される
https://docs.microsoft.com/ja-jp/azure/architecture/patterns/anti-corruption-layer

39. Anti-corruption Layer –問題と注意事項
 待機時間の増加、多くの場合問題となる
 管理および保守するサービスの増加は、システムの複雑性の増加となる
 スケーリングの実装、パーティション分割が必要になる可能性がある
 トランザクションおよびデータの整合性の担保
 管理、監視、リリース、および構成プロセスの統合
 処理範囲の検討
 異なるサブシステム間のすべての通信か、または機能のサブセットのみか
 アプリケーション移行戦略の一部である場合は、そのレイヤーを永続的
に使うか、すべてのレガシ機能が移行された時点で使用をやめるのかを
検討
kyrt inc 392018/4/20

40. Anti-corruption Layer –使い時
 サブシステムの移行に伴って、統合が壊れることを
防ぎたい
 Subsystem Bが、Version 1.xから2.xに移行する場合な
どの場合レイヤーを追加してSubsystem Aが利用してい
る機能のみを1.xから2.xへ変換等
 複数のサブシステムで構成されている場合
 Subsystem A,Bで構成されている、Bには旧システムの
データが存在する。アクセスはA経由としてB上のデータ
も提供する
kyrt inc 402018/4/20

41. Backends for Frontends
-フロント エンド用バックエンドのパターン
kyrt inc 412018/4/20
https://docs.microsoft.com/ja-jp/azure/architecture/patterns/backends-for-frontends

42. Backends for Frontends - 概要
フロント エンド毎に個別のバックエンド サー
ビスを作成する
 複数のインターフェイスのために 1 つのバッ
クエンドをカスタマイズすることが非効率な場
合に使う
Sam Newman の記事がオリジナル
kyrt inc 422018/4/20
https://samnewman.io/patterns/architectural/bff/

43. Sam NewmanのBFFから
General-Purpose API Backend
通常、単一のサーバーサイドAPIを提供し、複数
のタイプのUIに対応することから始める（左）
UIが似てるうちは良いが、モバイル、デスクトップ、
APIなどアフォーダンスが異なる。
モバイルとデスクトップはだいぶ違う
kyrt inc 432018/4/20

44. Backends for Frontends – 使うとき
 共有または汎用目的のバックエンド サービスを保守するために、多大な開発
オーバーヘッドがある
 特定のクライアント インターフェイスの要件に合わせて、バックエンドを最適化す
る必要がある
 複数のインターフェイスに対応するために、汎用バックエンドのカスタマイズが行
われている
 他のユーザー インターフェイスのバックエンドには、別の言語を使用したほうが
望ましい
このパターンは、次の場合には適切ではない
 各インターフェイスが、バックエンドに対して同一または類似の要求をする。
 バックエンドとのやりとりに使用されされるインターフェイスが 1 つしかない。
kyrt inc 442018/4/20

45. Bulkhead - バルクヘッド
kyrt inc 452018/4/20
https://docs.microsoft.com/ja-jp/azure/architecture/patterns/bulkhead

46. Bulkhead - 隔壁
 アプリケーションの要素をプールに分離し、1 つの
要素が失敗しても、他の要素が引き続き機能できる
ようにします。
 バルクヘッド (隔壁) という名前は、区分けされた船
体部分に似ていることから来ている
 船体が傷つけられた場合、水浸しになるのは破損し
た部分だけで、これによって船が沈むのを防ぐ
kyrt inc 462018/4/20

47. kyrt inc 472018/4/20
http://bit.ly/2HhCJbv

48. Bulkhead - 使うとき
 バックエンド サービスのセットを使用するのに使われているリソー
スを分離する。特に、サービスのいずれかが応答していない場合
でも、アプリケーションがなんらかのレベルの機能を提供できる場
合
 標準的なコンシューマーから重要なコンシューマーを分離
 エラーの連鎖からアプリケーションを保護
このパターンは、次の状況では適切でない
 プロジェクト内で、効率性の低いリソース使用は受け入れられない。
 複雑さを追加する必要はない。
kyrt inc 482018/4/20

49. Gateway系が２つ（OffloadとRouting）追加され
ているが、例がnginx で、lua スクリプト
＼(^o^)／
kyrt inc 492018/4/20

50. Gateway Offloading -
kyrt inc 502018/4/20
https://docs.microsoft.com/ja-jp/azure/architecture/patterns/gateway-offloading

51. Gateway Routing -
kyrt inc 512018/4/20
https://docs.microsoft.com/ja-jp/azure/architecture/patterns/gateway-routing

52. Strangler - ストラングラー
機能の特定の部分を新しいアプリケーションや
サービスに徐々に置き換えて段階的に移行
レガシシステムからの機能が置き換えられていく
と、新しいシステムは最終的に古いシステムの
機能すべてを置き換え、古いシステムを停止で
きるようにする
日本語で言うと、段階移行ってやつ
kyrt inc 522018/4/20
https://docs.microsoft.com/ja-jp/azure/architecture/patterns/strangler

53. Strangler - ストラングラー
kyrt inc 532018/4/20

54. もともとは
StranglerApplication by Martin Fowler
https://www.martinfowler.com/bliki/StranglerA
pplication.html
絞め殺しの木(Strangler Fig)
https://ja.wikipedia.org/wiki/%E7%B5%9E%E
3%82%81%E6%AE%BA%E3%81%97%E3%
81%AE%E6%9C%A8
kyrt inc 542018/4/20

55. Strangler - 使うとき
 バックエンド アプリケーションを新しいアーキテクチャ
に段階的に移行する場合に、このパターンを使用する
次の状況では適切ではない
 バックエンド システムへの要求がインターセプトできな
い場合
 システム全体の置き換えの複雑さが少ない、小規模
なシステムの場合
kyrt inc 552018/4/20

56. kyrt inc 562018/4/20
End