UD Day 20 オペレーショナル・モデル(RD)

オペレーショナルモデルでは、必要となるノードと各ノードにおける要件を論理(概念上必要となる単位でのまとめ)と物理(実際の配置のされ方)でまとめます。アーキテクチャの選定で、候補となりそうなプロダクトがわかってきているので、実際にオペレーショナルモデルに当てはめてみて、全体感がどのようになるかを掴みます。同時に、利用者数の規模をベースとしたスペック案についても考えてみます。
まず、大まかな対象(登場するシステム)ですが、以下のものになります(当然ですね)。

登場するシステム

1つ目の構成は一般的なウェブシステムの構成で、DBのプロダクトとしてMySQLを採用したものです。ノードは、左からLoad Balancer、Web、Application、Database(及びDatabaseの副ノード)、そして下段左が管理用ノードになります。それぞれの台数については、ここでは考慮に入れず、単純に役割別で登場し得るノードを記しています。基本は各ノードは単機能ですが、管理ノードについては、構成、監視を共存させています。これは、初期のコストを押さえるためのアイデアであり、分割することも当然考えられます。

web-ap-db(mysql)の標準的な構成

上記の構成に対して、ユーザー数の規模ごとにどのようなコストになり得るかを考えたものが、次の表です。ここでは、Case.0〜3までを記載していますが、4以降にも実際には続きます。各Caseで想定するGCPのノードタイプ、そして他に必要なもの(NWコスト、監視、ノード以外のストレージなど)の項目も用意しています。
Case0から右に行くに従って、ユーザー数が多い想定です。実際にはユーザー数がいくらくらいまで考えられるかも検討することもできますが、クラウドを利用するメリットはスケールアップ・アウトが容易である点を考慮すると、具体的な細かいユーザー数を事前検討することには実益はないと判断して省いています。ですので、これはあくまでもおおよそのイメージと捉えられます。
その上で、右に行くに従い、ノードの種類がよりハイスペック、ノード数がより多くなります。
セル背景色が緑、青の行は、それぞれMySQLの代わりにBigTableを用いる場合のコストとそれを含めた全体コストになります。Big Tableは製品としての魅力が非常に高い(分散性、レイテンシーの観点で優れている)ものですが、コストで比較した場合にはGCE&MySQLの構成の方が優れていることになります。(同じような理由から、GAEを採用していません。基本的な法則として、サービス対象が上位のレイヤーを含むほどコストも高くなるようです。)

ユーザー数規模に応じた構成例

基本的な考えは以上となりますが、要件定義の段階で考えた他のオペレーショナルモデルの例もここに付記します。

Web+App、redis、HBase

1つ目は、DBにredis+HBaseを採用した場合の構成です。分散性とレイテンシーを考えると良い構成だと思いますが、ノード数が多くなる欠点があり、採用していません。

GKE、Cassandra

2つ目は、ウェブ系と管理系にGKE、DBにCassandraを使った構成です。GKEは、全体のノードプールの中に複数の仮想ノードがあるというイメージです。リソースを十分に使うという観点で望ましいと思いましたが、DBに対しては適用し難く、結果として、GKEとGCEという2つの運用が存在することになるのが嫌だったので、採用しませんでした。

これ以外にもいくつかのパターンを考え、最終的な構成を決定しました。その構成は後の章で登場する予定です。(続く)

“UD Day 20 オペレーショナル・モデル(RD)” への1件の返信

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です