実は、スケールすると、システムを変える必要があるから
（クラウドだと「ソフトを変えなくても」スケールするというのは実は嘘）
例を挙げるとわかる。
お題：掲示板システムを作る
●最小限の構成：
・サーバーを１つたちあげて、PHPかなんかで組む。
・データをオープンソースのRDBに入れる（上記PHPと同一サーバー）
●信頼性をあげたい
・サーバーを１つたちあげて、PHPかなんかで組む。
・データをオープンソースのRDBに入れ
１台をマスタ、１台をスレーブとしてレプリケーションする
→サーバーは増えるが、ソフトの変化はない
＝予算は増えるが、開発工数は変わらない
●サーバー側のアクセス量が増える
・サーバー増設
複数サーバーが処理をする
・データをオープンソースのRDBに入れ
１台をマスタ、１台をスレーブとしてレプリケーションする
→ここ注意。要求を出す側は、ここで変化が無いと思っているが、
実際は
・スケールさせたり、インスタンスを消すためのシステムが必要
(AWSだと、cloud watch,cloud formationなど）
・セッションが使えるとは限らなくなってくる
→このレベル以上の場合、WebAPIで作ったほうが楽になる
→セッション in DBにするケースもある（後述の本質的対策でなく）
・DBアクセスが複数サーバー（動的になる）に対応
＝予算がかかる。インフラの力必要になる。実はソフト開発工数が増える★
●サーバーアクセスされるデバイスが増える
・レスポンシブWebデザインで開発
→ここ注意。要求を出す側は、レスポンシブでやればOKと思っている
実際は
・莫大なE2Eテストが必要。
・ios系(ipad,iphone)で問題を起こし、対応が必要になることしばしば
＝テストの（自動化）力必要になる。ソフト開発工数が思った以上に増える★
●サーバーアクセスされる国を増やす
・多国語対応すればよい
→ここ注意。要求を出す側は、画面を翻訳すればOKと思っている
実際は
・時間などをUTCベースで作っておかないといけないんだけど、
JSTで作っちゃっている場合ある
・画面の構造自体変わる
→多国語の構成管理が難しくなる
＝ソフト開発工数が思った以上に増える★
●サーバー側のアクセス量がもっと増える
・スケールすると思っている
実際は
・セッションin DBだときつくなる。なので、NoSQLに入れるか、セッションレスにする
→ソフトの改修が入る
→この段階で、後述するキューの利用を考える
・DBをマルチマスターにする場合がある
→SQLで、テーブル作るときに対応が必要なところもある
＝スケールさせると、ハード代高いことに、よほど鈍感出ない限り、このへんで気づく
ソフト開発工数が思った以上に増える★
●サーバー側のアクセス量がもっともっと増える
・安くするにはサーバーレスだ！と思っている
→ここ注意。要求を出す側は、
サーバーレスって、サーバーのプログラムを持っていくと思ってる
実際は
・根本的に書き方が違う（以下の理由で、マイクロサービスで記述する）
・RDBでサーバーレスをやると接続が持たないので、キューに入れる
→ソフトの改修が入る。アーキテクチャを見直し、APIベースのマイクロサービスへ
＝ソフト開発工数が思った以上に増える★、以前に、こういう開発を出来る人が少ない
上記★印のところで、ソフト開発が大幅にかかる。
だけど、はじめから、「サーバーレスでマイクロサービスで！」作れるのならいいけど
たいていは
・思った以上の予算がかかる（スケールしないのなら不要な予算）
・開発が難しく、人材が探せない
ということで、それは無理。
で、要求の段階で、トラフィックやトランザクションが見積もれても、
処理の書き方、サービスの選び方一つで、同じトラフィック、トランザクション
でも、上記のどの段階で開発をするかが変わってくる。
もちろん、それによりコストが変わる。
なので、
「実は、要求が決まっても、開発コストは見積もれなくなっている」、
むしろ、前に書いたけど、「要求が大事というのは古い時代の話」で、今は、
どう実装するかが大事だから、計画よりもPoC作って確認したほうが早いんだよねえ・・
（クラウドだと「ソフトを変えなくても」スケールするというのは実は嘘）
例を挙げるとわかる。
お題：掲示板システムを作る
●最小限の構成：
・サーバーを１つたちあげて、PHPかなんかで組む。
・データをオープンソースのRDBに入れる（上記PHPと同一サーバー）
●信頼性をあげたい
・サーバーを１つたちあげて、PHPかなんかで組む。
・データをオープンソースのRDBに入れ
１台をマスタ、１台をスレーブとしてレプリケーションする
→サーバーは増えるが、ソフトの変化はない
＝予算は増えるが、開発工数は変わらない
●サーバー側のアクセス量が増える
・サーバー増設
複数サーバーが処理をする
・データをオープンソースのRDBに入れ
１台をマスタ、１台をスレーブとしてレプリケーションする
→ここ注意。要求を出す側は、ここで変化が無いと思っているが、
実際は
・スケールさせたり、インスタンスを消すためのシステムが必要
(AWSだと、cloud watch,cloud formationなど）
・セッションが使えるとは限らなくなってくる
→このレベル以上の場合、WebAPIで作ったほうが楽になる
→セッション in DBにするケースもある（後述の本質的対策でなく）
・DBアクセスが複数サーバー（動的になる）に対応
＝予算がかかる。インフラの力必要になる。実はソフト開発工数が増える★
●サーバーアクセスされるデバイスが増える
・レスポンシブWebデザインで開発
→ここ注意。要求を出す側は、レスポンシブでやればOKと思っている
実際は
・莫大なE2Eテストが必要。
・ios系(ipad,iphone)で問題を起こし、対応が必要になることしばしば
＝テストの（自動化）力必要になる。ソフト開発工数が思った以上に増える★
●サーバーアクセスされる国を増やす
・多国語対応すればよい
→ここ注意。要求を出す側は、画面を翻訳すればOKと思っている
実際は
・時間などをUTCベースで作っておかないといけないんだけど、
JSTで作っちゃっている場合ある
・画面の構造自体変わる
→多国語の構成管理が難しくなる
＝ソフト開発工数が思った以上に増える★
●サーバー側のアクセス量がもっと増える
・スケールすると思っている
実際は
・セッションin DBだときつくなる。なので、NoSQLに入れるか、セッションレスにする
→ソフトの改修が入る
→この段階で、後述するキューの利用を考える
・DBをマルチマスターにする場合がある
→SQLで、テーブル作るときに対応が必要なところもある
＝スケールさせると、ハード代高いことに、よほど鈍感出ない限り、このへんで気づく
ソフト開発工数が思った以上に増える★
●サーバー側のアクセス量がもっともっと増える
・安くするにはサーバーレスだ！と思っている
→ここ注意。要求を出す側は、
サーバーレスって、サーバーのプログラムを持っていくと思ってる
実際は
・根本的に書き方が違う（以下の理由で、マイクロサービスで記述する）
・RDBでサーバーレスをやると接続が持たないので、キューに入れる
→ソフトの改修が入る。アーキテクチャを見直し、APIベースのマイクロサービスへ
＝ソフト開発工数が思った以上に増える★、以前に、こういう開発を出来る人が少ない
上記★印のところで、ソフト開発が大幅にかかる。
だけど、はじめから、「サーバーレスでマイクロサービスで！」作れるのならいいけど
たいていは
・思った以上の予算がかかる（スケールしないのなら不要な予算）
・開発が難しく、人材が探せない
ということで、それは無理。
で、要求の段階で、トラフィックやトランザクションが見積もれても、
処理の書き方、サービスの選び方一つで、同じトラフィック、トランザクション
でも、上記のどの段階で開発をするかが変わってくる。
もちろん、それによりコストが変わる。
なので、
「実は、要求が決まっても、開発コストは見積もれなくなっている」、
むしろ、前に書いたけど、「要求が大事というのは古い時代の話」で、今は、
どう実装するかが大事だから、計画よりもPoC作って確認したほうが早いんだよねえ・・
アクセス
トータル
ランキング
