# 4. アーキテクティング＆検証(チェック項目)

- [ ] 概要図作成
- [ ] 概要図がワークロード

# 4. アーキテクティング＆検証(前提基礎知識)

アーキテクティングの段階で、Well Architected Frameworkを参照しながら、問題のないアーキテクチャとなっているか確認。現時点で確認できない部分も、将来的に各パートで留意しなければならないポイントをToDo的に「いつ・何をするか」をまとめておく。

### 参考：Well Architected Frameworkとはなにか？
> Azure Well-Architected Framework は、ワークロードの品質向上に使用できる一連の基本原則です。 フレームワークは、優れたアーキテクチャの 5 つの柱で構成されています。コストの最適化、オペレーショナル エクセレンス、パフォーマンス効率、信頼性、セキュリティです。
>
文書リンク：　https://docs.microsoft.com/ja-jp/azure/architecture/framework/　

## ゲームサーバー タイプ

"ゲームサーバータイプ" とは、クラウド上に作成されるゲームサーバーの種類のことです。 たとえば、以下のようなものがあります。

- マルチプレイヤーサーバー
MMORPGやバトルロワイヤルゲームのようなゲームで使用されるのがマルチプレイヤーサーバーです。 リアルタイムサーバーやゲーム専用サーバーとも呼ばれます。一般的に常時接続型の通信を行い、ゲームサーバーとゲームのクライアントアプリケーションが常に接続された状態を維持することが多いです。通信プロトコルはゲームごとに独自実装を使うか、ゲーム通信エンジンと呼ばれるライブラリやミドルウェアを利用することもあります。
通信に使用するプロトコルはゲームごとに独自に定義したものを使うことが多いです。

- ゲームAPI サーバー
ゲームサーバーの中で、ゲームそのものの通信ではなく、ログインや、ガチャの抽選、ストアでのアイテム購入など、常時接続するほどのものではないものは、ゲームAPIと呼ばれる処理を用意します。このためのサーバーは、HTTP通信用サーバーとデータベースサーバーを用意し、一般的なウェブシステムに似た構成であることが多いですが、BaaSやGaaSと呼ばれるゲーム用のマネージドサービスを利用する例も増えています。
また、マッチメイキングやリーダーボードなどの特定の用途のサーバーは、複数のゲームタイトル間で再利用できる部品であるため、サーバーレスなどの基盤上に個別に実装されることも多いです。マネージドサービスとして提供されることもあります。

- ゲームメッセージ サーバー
ゲーム内でチャットメッセージの送受信を行う場合、サーバ側から任意のタイミングで送信を開始できる情報配信のためのサーバーが必要です。多くの場合は WebSocket などのウェブの技術を利用します。

- 分析用のサーバー
XXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXX

## アーキテクチャ スタイル

"アーキテクチャ スタイル" とは、特定の性質を持つアーキテクチャのグループです。 たとえば、n 層は一般的なアーキテクチャ スタイルです。 最近では、マイクロサービス アーキテクチャがよく使用されるようになりました。 アーキテクチャ スタイルによって特定のテクノロジの使用が必須となることはありませんが、一部のテクノロジは特定のアーキテクチャに適しています。 たとえば、コンテナーはマイクロサービスにとって最適なソリューションです。

- 3層 は、小規模から中規模のゲームタイトルでよく見る アーキテクチャです。 論理的な機能 (ゲームクライアント、サーバーロジック、データベースまたはキャッシュサービス) を実行する "レイヤー" に分割して依存関係を管理します。

- Web キューワーカー
マッチメイクなどの処理は、ユーザーの混雑状況に大きく依存するため、キューワーカー アーキテクチャを検討できます。 このスタイルでは、アプリケーションには HTTP 要求を処理する Web フロント エンドと、CPU 集中型タスクまたは実行時間の長い操作を行うバックエンド ワーカーがあります。 フロント エンドは、非同期のメッセージ キューを介してワーカーと通信します。

## グローバル対応や大規模対応をアーキテクチャに反映させる
- WAF、DDos
- 分散データベース
- スタンプ
- リージョン展開、計画
詳しくは後述？（別な章立てがあるはず）

## アーキテクチャ の検証方法

- どのような機能、ワークロードが必要か整理する
- ゲームサーバータイプを決定する
- 各ゲームサーバータイプに利用する主要なツール、テクノロジーを検討する
- 全体の概要、イメージ図を描く

"アーキテクチャ スタイル" とは、特定

- コストの最適化
- オペレーショナル エクセレンス
- パフォーマンス効率
- 信頼性
- セキュリティ

図解と処理は一緒に作成しているか？？

サンプル



Create a new game session
The device client formats any game settings selected by the player and sends the start game session event to the backend, then awaits a response.
The backend receives the command to start a new game session. First of all it tries to find an existing game session that matches the player settings.
Assuming a suitable game session is not available for matchmaking, a new game session object is created.
A new durable Orchestrator Function is created.
The durable Orchestrator Function reads the game session object and waits until at least 2 players have joined the game session.
Another player with the same settings as those selected by the first player sends a start game session event to the backend.
The backend receives the command and tries to find an existing game. In this case it finds the game session previously created.
The durable Orchestrator Function receives the addPlayer event and stops waiting as the 2 players have joined the game session.
The durable Orchestrator Function officially starts the match, setting the game state to in progress and randomly selecting one of the players to start. In a nutshell, the Orchestrator is responsible for executing the game logic and updating the game state.
The durable Orchestrator Function triggers an operation to persist the data into the database. It leverages the data client helper class to connect to the database to persist the data.
The durable Orchestrator Function runs the game session logic and returns that it's the turn of the next player.
It queues notifications to the player or players based on the game conditions (it's some elses turn, someone won, someone forfeited, etc).
The durable Orchestrator then invokes itself with the new game state, and waits for the next event to be received.
The device client receives the notification, including the unique identifier of the Orchestrator Function managing the game session.
The device client sends the load game session event to the backend, including the unique identifier of the durable Orchestrator received in the notification.
The backend receives the command to load the game session and returns the details of the game session to be displayed by the device client.
The player submits an X or a O directly to the durable Orchestrator Function and ends the turn.

Check項目 Ver. 0.1

- [ ] 必用なワークロードの洗い出し
- [ ] ゲームサーバータイプの特定
- [ ] ゲームサーバータイプから、アーキテクチャ概要図の作成
- [ ] 概要図に処理を書き込む
- [ ] アーキテクティングとMS技術陣によるレビュー・フィードバック
- [ ] Well Architected Frameworkの参照
- コストの最適化
- オペレーショナル エクセレンス
- パフォーマンス効率
- 信頼性
- セキュリティ

よくある懸念事項

- 販売計画・マーケティング計画がない　→　ユーザー負荷が分からない
- LAMPそのまま
- グローバル対応
- 分析がBIか機械学習かわからない

分析のレベル
1. BI
2. BI + ...
3. ML + ...
4. ....

Operation