2013-11-25
業務システムにおいてGAEでのインフラ費用が通常（オンプレミス）より安くなる訳：その1
先週書いた、『GAE（Google App Engine）での費用見積りについて：業務システムの場合』という記事が非常に好評を頂いたようで、アクセスが急増しました。
ありがとうございます。今後も出来る限りの内容を公開して、GAEでの業務アプリ開発を盛り上げて行ければなと思います。
さて、本日はその記事中でも触れた、表題のお話をしたいと思います。
私のこれまでの経験上、インフラの費用については大きく分けて以下の３点を考慮する必要があります。
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.3回（月30回とか）、管理者は月に2回DLを行う。
- 各業務をこなすのに必要なトランザクションを仮置きする
例えば、勤怠の1回の登録するにあたり全てAJAX通信で書き込み3回、読込5回とする。 - 上記トランザクションあたりのDataStore ReedとWriteを仮置きする
これはモデル設計にもよりますが、1transあたり10回とか20回とか、そういう数字になると思います。 - 上記をベースに1トランあたりのオンライン起動時間を見積り
1処理あたりのmsecを概算する。 - 1業務あたりのデータストア量を見積もる
これはメインのデータ量平均に対して3～5倍くらいを見ておく（Indexやログ等）ようなイメージです。 - 保存期間の仮置き
無限に保存するとすると無限になってしまうので、取り敢えず直近2,3年でみた時、とかそういう形で定時することが多いです。 - 個別要件での調整
例えばメール送信システムの場合はメール送信数が跳ね上がるのでそれは個別に盛り込みますし、SearchAPIやCloudStorageについては別途見積ります。 - 上記に課金額を入れて計算
細かい所は省きますが、後は上記で見積もった量に対して課金額を入れて行きます。 - ざっくりその他を倍から3倍として乗っけます
データDL量とか色々他にもあるんですが、それらはまぁ上記の見積りの倍から3倍って所でまずはざっくりといってしまいます。ここを精緻にやるのは神様でも無理でしょう。 - これまでの経験、近しいシステムの現況と比べての微修正
ある程度近しいPVとか想定される業務に近い既存システムとユーザ数や業務数等を考慮してマスで一応大きく違わないかチェック・微修正を行う
結局これまでの経験からはFrontEndの時間、DataStore Read/Write数、DataStore量、DLデータ、あたりが大半の課金金額を締めることになるので、主な部分を見積もって、それ以外は倍も行かないでしょうという経験則で出してしまいます。
勿論場合によってはもっと精緻にやってもいいでしょうし、稼働・テストしつつ見直しをするというのも時間と手間があれば是非やるべきだとは思います。
が、現実的には業務システムの場合上記で見積ると概ね相当低い金額になりますが、おそらくほぼそれで越えてしまうことは無い（概ね倍程度バッファ見てるので）ので問題にならないことの方が多いです。
以上、簡単ですが、当社で実施している見積りノウハウになります。
当社ではある程度ほぼ全てのシステムをIZANAMIフレームワーク化しているため設計・開発手法を似ているので、過去事例との比較がある程度容易・有意になる、と言った特徴があると思います。
こういった見積りだけ、などGAE導入の段階でお困り・お悩みの方へのサポートとして、当社でも『GAE導入支援サービス』として提供出来ますので、是非ご相談ください。
次回は何故GAEでのインフラ費用が通常（オンプレミス）より安くなるのか、ってところを考察してみようと思います。
→2013年11月25日公開『業務システムにおいてGAEでのインフラ費用が通常（オンプレミス）より安くなる訳：その1』
2013-10-07
開発案件失注
先日、RFIの提示から約１ヶ月に渡り提案活動をして来た案件の失注が確定しました。
ブライダル業界の案件で、結婚したこと無いのでブライダル業界本を2,3冊読み込んで、
それなりに力を入れて取り組んだ案件だったので非常に残念です。
自分で直接お客様にヒアリングした上で自分で提案して負けたのは記憶にある限り初めてのことなので、その辺りも若干ショックでしたねー。
数すくないけど負けたこと無い、ってのは自慢だったので。
その反省も含めて記載しておこうかなと思いました。
RFI上は、以下のように読み取れました。
-業務理解が第一である
-実現性が無いとダメ
-同等の実現範囲の場合は価格が決めてになる
結論としては、価格が高い、ことがネックになりさっくり落とされてしまった感じです。
GoogleApps＋GAEでの非常に先進的な提案だった点は評価頂いたのですが。
この優先度を鵜呑みにしてしまったのが間違いだった、と。
やはり予算枠はあるわけで。何でもかんでも実現すれば良いということでは無いですよね、と。
まぁそりゃそうなんですが、今回はそこが少し気になったので、要件定義をしっかりやりたいという提案で良いか事前に確認したのですが、、、、
予算感もちゃんと確認しておけば良かったです。そこに向けてある程度前提事項を調整しないとダメだったなぁ、と。全然ずれた提案になってしまっていたと言うことのようで。
まぁでもオープンソースのパッケージをベースにしたカスタマイズってのと比べるとさすがに費用では勝てないわなぁ。。。
いやぁ、残念でした。ご協力頂いた皆様ありがとうございました。
また、採用された方のシステムが無事完成することをお祈りしております。
次回以降の反省として。
2013-09-11
2013-09-10
Google Apps Certified Deployment Specialist 再度合格
以前日本で一番で合格したDeployment Specialistですが。
18ヶ月の期限がありまして。
猶予期間が2ヶ月あったので、ぎりぎりになりましたが先日合格し、見事延長となりました。
8周年記念の翌日の土曜日でしたが、頑張った、おれ！
以下がその証拠のメールです。下の合格のメールが16：34、上のExpireのメールが17時ジャスト。（恐らくカリフォルニア時間の0時なのかな？）
本当にぎりぎりのギリギリでしたー。こんな人なかなか居ないだろうな。。
今回も非常に難しかったのですが、なんと時間が無くてほぼNo勉強で。。。
その中で150分、頑張りました。日本語だったのでやはりその点は良かったですね、時間余ったし。
いやらしい問題が多かったので、よく出来てるなぁ、という印象。
ちなみに、やっぱり未だBlackBeryの問題が出るので、何とかして欲しいものです。
Notesの移行の問題や、Chrome for Businessの問題も何問か出てきたのですが全く分からなかったので、完全ヤマカンでした。
しかし、これで受かるなら今後何度でも受かれるな、少なくとも何度か受ければ。（運が良ければ）
以下は初合格の時のブログです。
http://yoshidumi.blogspot.jp/2012/01/google-apps-certified-deployment.html
いやぁ、ホント、良かった良かった！
2013-09-07
8周年
皆様に支えられ、遂に吉積情報も8周年を迎えました。
昨日は40名近くの社員・家族・協力会社等の皆様と船上パーティで8周年をお祝いすることが出来ました。
毎年ここだけは、無い袖を振り絞ってのお祝いです。本当に感慨深いものでした。
今年は、GAEでの業務システム開発が本格的になって来て、非常に面白いことになって来ております。
昨日訪問したお客様先でもGAEの開発だと一番ですね、と言って頂きました。ほんと、嬉しいです。
で、「いや、ダントツの一番を目指してますから」と応えておきました。
社員のみなさん、よろしく、がんばりましょう！
後でパーティ画像は共有する予定。誰か送ってくださいー。
登録:
投稿 (Atom)