オペレーショナル・モデル(RD)オペレーショナルモデルでは、必要となるノードと各ノードにおける要件を論理(概念上必要となる単位でのまとめ)と物理(実際の配置のされ方)でまとめます。アーキテクチャの選定で、候補となりそうなプロダクトがわかってきているので、実際にオペレーショナルモデルに当てはめてみて、全体感がどのようになるかを掴みます。同時に、利用者数の規模をベースとしたスペック案についても考えてみます。大まかな対象(登場するシステム)ですが、以下のものになります(当然ですね)。登場するシステム1つ目の構成は一般的なウェブシステムの構成で、DBのプロダクトとしてMySQLを採用したものです。Balancer、Web、Application、Database(及びDatabaseの副ノード)、そして下段左が管理用ノードになります。それぞれの台数については、ここでは考慮に入れず、単純に役割別で登場し得るノードを記しています。基本は各ノードは単機能ですが、管理ノードについては、構成、監視を共存させています。これは、初期のコストを押さえるためのアイデアであり、分割することも当然考えられます。上記の構成に対して、ユーザー数の規模ごとにどのようなコストになり得るかを考えたものが、次の表です。ここでは、Case.0〜3までを記載していますが、4以降にも実際には続きます。各Caseで想定するGCPのノードタイプ、そして他に必要なもの(NWコスト、監視、ノード以外のストレージなど)の項目も用意しています。Case0から右に行くに従って、ユーザー数が多い想定です。実際にはユーザー数がいくらくらいまで考えられるかも検討することもできますが、クラウドを利用するメリットはスケールアップ・アウトが容易である点を考慮すると、具体的な細かいユーザー数を事前検討することには実益はないと判断して省いています。これはあくまでもおおよそのイメージと捉えられます。その上で、右に行くに従い、ノードの種類がよりハイスペック、ノード数がより多くなります。セル背景色が緑、青の行は、それぞれMySQLの代わりにBigTableを用いる場合のコストとそれを含めた全体コストになります。Tableは製品としての魅力が非常に高い(分散性、レイテンシーの観点で優れている)ものですが、コストで比較した場合にはGCE&MySQLの構成の方が優れていることになります。(同じような理由から、GAEを採用していません。基本的な法則として、サービス対象が上位のレイヤーを含むほどコストも高くなるようです。基本的な考えは以上となりますが、要件定義の段階で考えた他のオペレーショナルモデルの例もここに付記します。Web+App、redis、HBase1つ目は、DBにredis+HBaseを採用した場合の構成です。分散性とレイテンシーを考えると良い構成だと思いますが、ノード数が多くなる欠点があり、採用していません。GKE、Cassandra2つ目は、ウェブ系と管理系にGKE、DBにCassandraを使った構成です。GKEは、全体のノードプールの中に複数の仮想ノードがあるというイメージです。リソースを十分に使うという観点で望ましいと思いましたが、DBに対しては適用し難く、結果として、GKEとGCEという2つの運用が存在することになるのが嫌だったので、採用しませんでした。これ以外にもいくつかのパターンを考え、最終的な構成を決定しました。その構成は後の章で登場する予定です。コメントをキャンセルメールアドレスが公開されることはありません。inc.の会社ホームページです。inc.の会社ホームページです。