2013-11-29

業務システムにおいてGAEでのインフラ費用が通常(オンプレミス)より安くなる訳:その2


業務システムにおいてGAEでのインフラ費用が通常(オンプレミス)より安くなる訳:その1』の続きですので、未だお読みで無い方はまずそちらをお読みください。

インフラに関わる費用としてざっくり以下がありますが、このAについてはお話しました。
>A.インフラ自体の購入・保守サポート費用
>B.上記の組み上げ・保守費用
>C.運用管理設計、導入費用・保守費用

Bについて書きますと。
ここはまさにSIerの構築ノウハウをベースに、必要な性能を達成させるべく購入した製品を組み合わせ、設定して、テストする、という一連の作業になります。EC2とかIAASのサービスを使っても通常このレイヤの作業は必要になります。
確かに、昔は(10年くらい前とか)色々なサービス毎に異なるSLAを設定し、それぞれに適切な構成、というのがあったしそうする意味もあったのですが。
ここ数年で言うと、業務システムに求められる要件て同じで、私がインフラ構築を提案する時にふと全く同じ事をしていることに気づきました。

簡単にいうと以下のようなものです。分かる人だけ分かればいいですが。
VMWareをベースにブレードを並べてリソースプールを作成して、DBサーバだけ別途4Uくらいのを購入、ストレージはそこそこ高価なものにしておき筐体単位でのバックアップは基本取らない(お金に余裕があれば2台構成にしてDR)、代わりに筐体内では全て冗長化される構成のストレージを購入。
DBMSにOracleを入れ、ストレージの機能との組み合わせでスナップショットを取って、テープにゆるりとバックアップしていく。
監視は監視サーバ・MWを入れて、JP1等を入れてスケジュール連携する。

これ、ほぼ全く同じで無いですか?
また、ここに関わるコストも馬鹿になりません。監視サーバとかJP1とかってそれなりに高価ですし、ストレージの冗長化とかの設計とかストレージの論理領域を切ってもらったり、ストレージの冗長化とかってびっくりするほど高価なSI費用を請求されます。(特殊技能だからでしょうけど)
繰り返しになりますが、これもGAEだと不要です。


私は行くプロジェクト毎に毎回9割方同じ設計書を書いて、ベンダーさんに組み上げて貰ってテストして。。。。
ばかばかしい、と。
このレイヤに価値がある時代は終わりました。
システム(インフラ)に求められる要件は、
-止まらない
-データなくならない
-スケーラビリティが確保されている
-セキュアである(データを持って行かれない)
-アプリの変更が容易
これで全てだと思います。皆ほぼ同じです。で、既にそのインフラはあるのです。
GAEではこのレイヤも全く必要ありません。これがEC2等の通常のIAASと大きく異るところです。


Cについて
監視やバックアップの仕組み、またそこで障害発生時やパッチ適用時に発生するコストです。
ここについては、GAEでもある程度(構築部分以外の運用)は必要になります。

運用って例えば、1回何らかエラーが吐かれたとしたら、
その調査を行い、再現性があるのか無いのか、リスクは?等の判断をして、対処の優先順位(対応しない)を決めて、
他の仕様変更とかと合わせてリリース計画を立てて、利用者側に告知して、(場合によっては夜間)リリース作業する。
という流れを全て調整してやってかなきゃいけませんが。

が、インフラレイヤの障害に対応する必要がほぼなくなりますので、その分まるまる対処必要無くなります。
実際、3年くらい全くノータッチで動いているものも弊社の管理している中にはあります。(そのぐらい通常システムでもあり得ますけどね)

まぁその部分はそれほどGAEと他とで違うってことは無いように多みます。
逆にAPIにはある程度依存するのでその変化の速度等が通常の枯れたフレームワーク等と比べると多いかも知れないので、それには対応する必要があります。
そこの点は敢えて書いておきますがデメリットになり得ます。

とは言え、総じてA,B分のコスト減がかなり大きいので、私としては構築難易度やAPI等の変更の速度が早いことに対する対処はプログラム上の工夫でかいけつしてしまって、インフラレイヤ迄クラウドで吸収する、という形で圧倒的な低コストが実現出来ると考えて居ます。

以上、インフラのコンサルタントとしての視点から見たGAEで安くなる理由でした。
次回は、apps-gaeの興味深い記事について私の目線から幾つか紹介させていただこうと思います。

2013-11-25

業務システムにおいてGAEでのインフラ費用が通常(オンプレミス)より安くなる訳:その1



先週書いた、『GAE(Google App Engine)での費用見積りについて:業務システムの場合』という記事が非常に好評を頂いたようで、アクセスが急増しました。
ありがとうございます。今後も出来る限りの内容を公開して、GAEでの業務アプリ開発を盛り上げて行ければなと思います。

さて、本日はその記事中でも触れた、表題のお話をしたいと思います。
私のこれまでの経験上、インフラの費用については大きく分けて以下の3点を考慮する必要があります。

A.インフラ自体の購入・保守サポート費用
 →HW/MW/OSの購入代金と保守サポート費用です。当然ですね。

B.上記の組み上げ・保守費用
 →上記を業務要件に合わせた形で組み上げて、テスト含めて動作・保証する費用です。SI費として計上されることが多いですが、しっかりテストすると結構馬鹿になりません。

C.運用管理設計、導入費用・保守費用
 →バックアップ・リカバリや監視等の仕組みを構築、導入し、障害時の切り分けルールやワークフロー等を整備し、それを運用して行く費用です。
  これには、障害レベル・レイヤ(HW層、データセンタ層、OS層etc)に応じたワークフロー定義や障害が発生した際にどこまで検証するのかなどの定義とその都度の確認等の時間も含まれます。

ざっくり私の感覚で分けるとこんな感じになります。
一口に「インフラ」と言うと広義にはフレームワーク定義や実装とその業務システム開発チームへの展開まで含めて呼ぶ場合もありますが、ここでは実行・開発・運用環境を担保する、という所までとしておきます。

ここにおいて、個別にGAEとオンプレとでの費用イメージを比較して行きますが。
私のざっくりしたオンプレでの費用感のイメージは非常に大雑把ですが、
A:B:C=5:3:3 くらいの感触です。
(値引きをどこで頑張るかとか、何年運用するかによってもかなり誤差がありますが)

1点目のAについて、まずはGAEにおいては初期の購入費用は全く不要ですね。ここが非常に強調されるところでもあります。

業務システム開発においてどのようなHWを用意するかというと。
まず、通常のオンプレのシステムの平均CPU利用率なんかは10%を切るのはザラであります。ある程度見積りがうまく行ったとしてもシステム屋さんの考え方だと40%を超えるともう追加が必要という認識に至ります。最近は仮想化前提としても4割を超えるとリソース追加しようと言う話が出てくるはずです。要は必要なリソースの何倍かの箱を用意するということになります。
また、業務システムにおいては冗長構成を取る部分に非常に費用がかかります。
余剰な性能の担保+冗長構成が必須、の2点を考えるだけでどれだけAの費用が業務システムで過剰に必要になるかがわかると思います。
GAEは利用した分だけしか請求が来ません。冗長化についてのコストはその中に完全に含まれていますが、おそらく全体で共同担保しているという設計の関係上個別に見たらほぼゼロに限りなく近いレベルの冗長化コストなのでは無いでしょうか。

また、ここで運用設計とも絡んで来ますが、仮想化してリソースプール化するのは良いのですが、考えなきゃイケないのが稼働のインスタンスをどのように分割するか、です。
一般的に業務システムにおいてはその責任分界を非常に厳密に仕切りたがることが多いです。作る所管が違うとなおさらです。なので、非常に小さなリソースしか必要無いシステムでも責任分界上そのまま別のOSである必要が出てきます。(Tomcatあいのりで全然良いじゃん!ってものでも)
仮想化して気軽に出来るようになってるので、なおさらその傾向は高いと思います。
そうすると必要になってくるのが、じゃぁそのOSは誰が管理すんの?パッチ誰が当てるの?という話です。
GAEでは勿論いくつでも必要に応じてapp-idを作れますが、そこに付随する追加コスト(運用保守料)は一切ありません。何ならapp-idを分ければ分けるだけ無料枠が増える格好になります。

ちょっと長くなって来たので、B,Cの観点については次回にしたいと思います。

ちなみに、GAEの無料枠でどこまで使えるのか、という記事がapp-gaeにあります。


2013-11-22

引っ越しました!八丁堀と新富町の中間

少し遅くなりましたが、先月引っ越ししました!
新しいオフィスは以下の広さです。奥に見えるのが入り口でワンフロア丸々です。
新富HJビル4F

上記の写真の左奥側から撮ったもの。
 皆様遊びに来てください。
年明け迄には会議室を作りたいなぁと思ってます。

以下、丸3年お世話になった銀座オフィスを最後に。Paulにはまた行きますが。

取り敢えずこの新しいオフィスで30人超までは頑張るつもりです。さて、何年で出て行かざるを得なくなるのか。

2013-11-19

GAE(Google App Engine)での費用見積りについて:業務システムの場合


GAEの導入にあたって良くある質問の費用見積りについてです。

弊社で良くやる方法でして、これが100%ではありませんが概ね問題無いというものですが、
参考になればと言うことでまとめてみます。

まず、前提としては業務システムであるということで、特徴として。
-ユーザ数は少なめ
-利用量は人・業務によって多かったり少なかったり幅広い
-可用性は結構必要
-アクセス時間は結構偏る

という所が言えると思います。

この場合に弊社でGAEの利用料を見積もる場合には以下のステップで行います。


  1. 業務毎に仮の業務量を調べる勤怠登録は修正も想定して一人が必ず1日1.3回(月30回とか)、管理者は月に2回DLを行う。
  2. 各業務をこなすのに必要なトランザクションを仮置きする
    例えば、勤怠の1回の登録するにあたり全てAJAX通信で書き込み3回、読込5回とする。
  3. 上記トランザクションあたりのDataStore ReedとWriteを仮置きする
    これはモデル設計にもよりますが、1transあたり10回とか20回とか、そういう数字になると思います。
  4. 上記をベースに1トランあたりのオンライン起動時間を見積り
    1処理あたりのmsecを概算する。
  5. 1業務あたりのデータストア量を見積もる
    これはメインのデータ量平均に対して3~5倍くらいを見ておく(Indexやログ等)ようなイメージです。
  6. 保存期間の仮置き
    無限に保存するとすると無限になってしまうので、取り敢えず直近2,3年でみた時、とかそういう形で定時することが多いです。
  7. 個別要件での調整
    例えばメール送信システムの場合はメール送信数が跳ね上がるのでそれは個別に盛り込みますし、SearchAPIやCloudStorageについては別途見積ります。
  8. 上記に課金額を入れて計算
    細かい所は省きますが、後は上記で見積もった量に対して課金額を入れて行きます。
  9. ざっくりその他を倍から3倍として乗っけます
    データDL量とか色々他にもあるんですが、それらはまぁ上記の見積りの倍から3倍って所でまずはざっくりといってしまいます。ここを精緻にやるのは神様でも無理でしょう。
  10. これまでの経験、近しいシステムの現況と比べての微修正
    ある程度近しいPVとか想定される業務に近い既存システムとユーザ数や業務数等を考慮してマスで一応大きく違わないかチェック・微修正を行う



結局これまでの経験からはFrontEndの時間、DataStore Read/Write数、DataStore量、DLデータ、あたりが大半の課金金額を締めることになるので、主な部分を見積もって、それ以外は倍も行かないでしょうという経験則で出してしまいます。

勿論場合によってはもっと精緻にやってもいいでしょうし、稼働・テストしつつ見直しをするというのも時間と手間があれば是非やるべきだとは思います。

が、現実的には業務システムの場合上記で見積ると概ね相当低い金額になりますが、おそらくほぼそれで越えてしまうことは無い(概ね倍程度バッファ見てるので)ので問題にならないことの方が多いです。

以上、簡単ですが、当社で実施している見積りノウハウになります。

当社ではある程度ほぼ全てのシステムをIZANAMIフレームワーク化しているため設計・開発手法を似ているので、過去事例との比較がある程度容易・有意になる、と言った特徴があると思います。

こういった見積りだけ、などGAE導入の段階でお困り・お悩みの方へのサポートとして、当社でも『GAE導入支援サービス』として提供出来ますので、是非ご相談ください。


次回は何故GAEでのインフラ費用が通常(オンプレミス)より安くなるのか、ってところを考察してみようと思います。
→2013年11月25日公開『業務システムにおいてGAEでのインフラ費用が通常(オンプレミス)より安くなる訳:その1