GCE解説その1：GCE概要

今年はGCEもやってくぞと言うことで、何回かにわたってGCEについて書いていこうと思います。
まず第一回として、GCEの概要についてです。
基本はGoogleのGCEの概要ページを見ていただくのがまずは早いです。（日本語だと限定プレビュー版とかの記載が残ってしまってますね。。）

GCEとは

まず、『GCE』とは、Google Compute Engineの頭文字を取ったものです。（当然ながら）
当然ご存知とは思いますが、Googleのクラウドプラットフォームの中の一部として位置づけられております。
Googleのクラウドプラットフォームとは、これまたGoogleのクラウドプラットフォームの製品ページを見るのが早いですが、主に以下の6つの製品群から成り立ちます。
-Compute Engine（コンピュートエンジン）
-App Engine（アップエンジン）
-Cloud SQL（クラウド・エスキューエル）
-Cloud Storage（クラウド・ストレージ）
-Cloud DataStore（クラウド・データストア）
-Big Query（ビッグクエリ）

Googleクラウドプラットフォームについて

それぞれ簡単に説明しますと。
-Compute Engine

一言で言うと一般のIaaS（Infrastracture as a Service Wikipedia参照）です。EC2相当のサービスです。（本稿のメイン）

-App Engine

一言で言うとPaaS（Platform as a Service）なのですが、JavaやPython等のプログラムソースのみ準備すればすぐに動作させられるプラットフォームという点が非常に特徴です。

弊社でイチオシの基盤です。

-Cloud SQL

RDBMSレイヤのPaaSです。裏側ではMySQLが動きます。

-Cloud Storage

ファイルストレージです。AWSで言うところのS3と同等のサービスですね。

-Cloud DataStore

GAEでもともと使われていたKey-Value型のデータ保存領域です。GAEでなくても利用出来る様になったのですが、これと言った用途が思い浮かびません。GAE間で共有するような場合には良いのかも知れないですが、もう少しGAEが流行ってからだろうなと思います。

-Big Query

大規模なデータ解析を安価に高速に行えるサービスです。数Tというデータに対して全文検索（フルスキャン）のクエリかけても数十秒で返却される、というものです。ビッグデータ時代に対応したサービスです。アーキテクチャ的には全部読みに行くけど、大量のインスタンスを裏で立ちあげて並列処理するという力技というかある意味男らしいソリューションです。Googleのクラウドならではの解決方法だと思います。

GCEの基礎知識

さて、本題のGCEですが。まずは、Googleの概要ページの中の「特徴と機能」や、私の翻訳した「AWSよりGoogle Compute Engineを選びたくなる10の理由」をまずは読んで頂ければと思います。

私の現時点でのまとめとしては

1. 基本機能は揃っており、問題無く使える
2. OSとしてWindowsが選択出来ない点がかなり問題
3. 利用開始は非常に簡単且つ楽
4. 価格はAWSとそれ程変わらない（どっちもどっちな印象）
5. I/O性能は非常に高速
6. Googleの他サービスとの組み合わせをするなら非常に有効
7. 細かい機能においてはAWSに劣る面もまだまだあるように思われる

という印象です。

特に6点目についてはやはり、レイテンシの観点で、GoogleMapやGoogleApps等と連携するWebサービスを展開するなら是非検討に入れるべきと思います。Googleの高速なクローズドネットワーク内で処理が簡潔するので、インターネット経由とは比べ物にならないレイテンシになると思います。

この点については別途処理性能検証を行う予定なので、乞うご期待です。

次回はGCEの価格について

次回は価格について、以下の視点で評価してみようと思います。

-各インスタンスタイプ別のAWSとの比較

-ディスク・スペースの比較（Cloud Storageとどうなのか？等）

-In/Outのデータ転送量課金のAWSとの比較

GoogleAppsと業務システムと

最近営業とかに行くとで話題になるのが、GoogleApps及びGoogleソリューションを活用するアイディアって何だろう？という話です。
ちなみに、オチ無いです。。。

以下の観点からそのあたりのソリューションと言うか、具体例とかが求められているように思います。

・GoogleAppsの販売側の観点
　GoogleApps単体での販売ではGoogleApps販売会社間での差別化がしづらくなっていることと、さらなるGoogleならでは感を出したいと言うこと。

・GoogleApps導入済企業の観点
　GoogleAppsの利用をもっと促進したい、Google周りのソリューションをもっと活かしたい、けどいろいろ出来るんだろうけど何が出来るのか分からない。

・弊社のようなGoogleソリューションの提供ベンダの観点
　何でも作れるんだけど、具体的に営業をがっつりまわるだけの顧客に刺さるソリューションが無いと面展開しては売りづらい。

それぞれのステークホルダーが皆必要性を感じては居るのですが、明確に『これ』という解が無いように思います。
突き詰めると結局ASPやパッケージvsカスタムソリューションの話になってしまうようにも思うのですが、このクラウド時代、もう少しスマートな提案が出来ないものか正直、苦慮してます。
マーケットプレイス上に商品を並べて、組み合わせの提案だけする。とかってのが簡単に出来るとそれもひとつの手かなとは思うのですが、どうでしょうか。。。

取り敢えず目の前のソリューション提案や、普及活動をしっかりやって行きつつ、上記をスパッと解消するアイディアが何か無いものかと日々模索しています。
オチなくてすみません。

AWSよりGoogle Compute Engineを選びたくなる10の理由

Google Compute Engineについて興味深いブログがあったので、勉強を兼ねて和訳してみました。
原文はこちらです。

以下、超訳。

昨年（訳注2012年のこと）、GCEとしてGoogleがIaaSの提供を発表した時に、amazonは心配するべきかどうか聞いてみた。18ヶ月後、Google Compute Engineは一般公開され、信頼性、価格、革新性において間違いなくAWSの競合になったと見受けられる。混雑したIaaS市場には多くの新規参入があり、そのいくつかはマイクロソフト、HPとIBMのような十分に確立された企業·ベンダーである。しかし、大多数のそうしたサービス群は限定的な機能しか持たない。彼らはAWSに対抗することは諦め、Amazon EC2の2008年相当のものに見えた。しかし、GCEはそのアプローチからして異なる。Amazon EC2の類似機能に焦点を置くのではなく、GoogleはAmazon EC2に存在するギャップを埋めることにフォーカスした。AWSの顧客によって永らく、多くののフォーラムでこれらの課題が持ち上がっていた。GCEはAWSの既存顧客を惹きつけるために、これらを優美な方法で取り組んだ。
ここにAWSよりGoogle Compute Engineを選びたくなる10の理由を記載します。

1.価格と1時間未満での課金

Amazon EC2ではインスタンスの利用料が時間単位で課金されます。一部の時間しか使わなくても1時間に丸められて請求されるのです。GCEのマシンタイプでは10分が最小単位になります。10分経過後は、1分単位の課金（切り上げ）になります。まずこの比較ではGCEの計算能力とストレージのコストはAmazon EC2より安いと言えます。

2.ロードバランサーのプレWarmingが必要無い

AmazonのElasticLoadBalancer(ELB)は突然のスパイク（急激なアクセス増）を適切に扱うように設計されておらず、顧客はAWSにプレWarmingを申請し、ELBが想定リクエスト量に対応出来るように準備しておく必要があります。これはAWSサポートのサブスクリプションが必要ということになります。GCEのロードバランサーはプレWarmingは必要ありません。突然のスパイク的なトラフィックについても即座に対応するようスケールします。詳細は『ComputeEngineのロードバランサーは百万リクエスト/秒を処理（本文は英語）』を参照ください。

3.複数のVMに接続可能なPersistentディスク

GCEのPersistentディスク（PD）は一つのVMから読み書き可能でマウントするか、複数のVMから読み取り専用でマウントすることが出来ます。Amazon EBSは同時にひとつのインスタンスにしか紐付けられません。これだと静的コンテンツをインスタンス間で共有するための同期機構を顧客が用意する必要があります。この点については、『Amazon Web Serviceが直すべき5つの理由(本文は英語)』を参照ください。

4.優れたブロックストレージ

GCEのPersisitentディスク（PD)はAmazon EBSがサポートする10倍の10TBまでの容量をサポートします。Amazon EBSと違い、GCEのPDはI/Oの価格を含みます。これは、顧客にとって余計な推測作業を省き、より正確な価格見込みが可能になることを意味します。これは本当にゲーム・チェンジです！詳細は『新しい通常ディスク-GoogleComputeEngineのため、より速く、より安く、より予測可能な（本文は英語）』を。

5.統合されたネットワーク

Amazon Virtual Private Cloud（VPC）はAmazon EC2の公開から2年遅れて登場しました。Amazon EC2上のネットワーキングは後付であり、顧客がVPC環境にEC2の大規模なデプロイをするのを困難にしています。GCEにおいては、ネットワークは第一優先度で考えられており、顧客は仮想ネットワーク、プライベート、パブリックサブネット、ファイヤーウオール、ルーティング、ゲートウェイ、ACL等の環境を最初のVMを立ちあげる前に作成出来ます。Amazon VPCと異なり、ネットワークは別のサービスではなく、GCEの統合された一部なのです。GCEのドキュメントの『ネットワーキングとファイヤーウオール(本文は英語)』の章を参照ください。

6.よりよいネットワークスループット

GCEのリージョンを跨ったネットワーク I/OはAWSよりも断然速い。Googleがオフィシャルに認めたわけではないが、Googleのインフラのバックボーンとして使われているグローバル・ネットワークを活用していることは明白です。対照的に、AWSではリージョン間の通信に一般のインターネットを使っています。このGCEの能力により、リージョン間を跨いだデータベース同期機能のような興味深いシナリオを描くことが出来ます。

7.マルチリージョンイメージ

Amazon EC2では最近、リージョン間でのAMIコピー機能が追加されましたが、なお明示的にAMIのコピーを実施する必要があります。GCEにおいては、全てのOSイメージは一つのグローバルリソースとして存在します。それはGoogleが顧客から預かったカスタムイメージを含めてグローバルなイメージリポジトリを維持していると言うことになります。詳細はGCEのドキュメントの『リソース概要(本文は英語)』の章を参照ください。

8.持続性IPアドレス

Amazon EC2のElastic IP（EIP）と違い、GCEのリザーブドIPはVMの再起動によって変更されません。GCEではまた、既存の割り当て済一時IP（エフェメラルIP）をリザーブドIPに昇格させることも出来ます。これにより、一時IPについて作成した初期DNSレコードをそのまま保持することが出来ます。Amazon EC2上では、EIPはVMの起動時に紐付けられている必要があります。GCEのリザーブドIPアドレスについての詳細は『インスタンスとネットワーク(本文は英語)』参照ください。

9.より速い起動時間とVMの自動再起動

GCEのVMの起動時間は少なくともAmazon EC2の5倍は高速です。セバスチアン・スタンジル氏は言う、"VMのデプロイと起動は驚異的な速度でした（我々は広範囲に10クラウド利用している）。VMの起動コマンドをたたいてからrootでログインが出来るようになるまで、常に30秒以下です。"Google Compute Engineは自動再起動設定を利用することで、ハードウェア障害やすスケジュールメンテナンスイベントなどシステム依存の停止が発生した場合に自動的にインスタンスを再起動させることが出来ます。これによりインスタンスの自動治癒が有効になるのです。詳細は『インスタンス-Google Compute Engine- Google開発者(本文は英語)』を参照ください。

10.ライブマイグレーション

全てのクラウド事業者は必ずホストしているサーバやデータセンタをメンテナンスする必要に迫られます。これにより結果として、スケジュールドダウンタイムが発生し、クラウドベンダーはこのプロセスを完了させるために顧客にVMの再起動をしてもらう必要があります。『Amazon EC2 メンテナンスヘルプページ(本文は英語)』にこのプロセスについて記載があります。『広範囲に渡るAmazon EC2クラウドインスタンスの再起動により疑問や懸念が発生(本文は英語)』という記事でEC2インスタンスの強制再起動問題に触れられています。GCEではこれをVMをホスト間でグレイスフルライブマイグレーションを行うことで顧客に対しても明確に問題が無いことを示しています。より詳細についてはGCEドキュメントの『リージョンとゾーン-Google Compute Engine-Google開発者(本文は英語)』の章を参照ください。


以上、AmazonはGCEを恐れるべきでしょうか？皆さんのご意見をお聞かせください。

ここまで、超訳でした。

ここまでお読み頂いた方には、AWSとGCEのI/O比較した記事も参考になるかと思います。

個別の感想については後日書きます。いやぁ、久しぶりに和訳ってやったなぁ。
間違ってるとかありましたらご指摘いただけると幸いです。

新年の抱負2014

旧年中は皆様お世話になりました。

この一年はメンバを急拡大させたことや新規事業の立ちあげもあり、若干苦しい自分もありましたが、
昨年採用したメンバも含めて頑張ってくれたので何とか年を越せました。
本当にいつもお世話になっている皆さん、社員の皆さんには感謝しか無いです。

恒例の昨年の目標のふりかえり、今年の目標を記載したいと思います。

■昨年の目標のふりかえり

・GAEの業務システム開発No1の座を確固たるものにする！

>この分野では圧倒的なNo1を目指します。
>ベトナムとの協業体制も組み、柔軟な開発体制を敷けるよう、案件と両輪で拡大をしていきます。
確固たるところまでいけてるかどうかは分かりませんが、かなりイイ線迄は行ってると思います。
昨年の実績として、取り敢えず、実績の無い会社さんが一から全国で探して、ウチをパートナーとして選んで頂き、
50人月以上の開発のお手伝いをさせて頂く機会を貰ってます。
この調子で、案件開発と要員の調達の両輪を今年も邁進します。

・売上2億！人員20名！

>恐らく本年の売上着地が1.2億位になると思います。昨年対比で1.5倍くらいは行ってるので、
>この流れを継続します。もう少し欲をかいて2億の大台を目指したいと思います。
>今年こそは退職者ゼロを。。。。
ちょっと継続は出来ませんでした。。。ほぼトントンからちょっと上くらいかと。
具体的には新しくそこそこの規模の業務システム開発を始めたところ、正直いろいろトラブりまして、
売上拡大に力を入れる余裕が無かったことが原因でした。何とかその経緯を血肉として今年こそ。
退職者ゼロも達成出来ませんでしたね、1名は出てしまいました。
これはそろそろ15,6名まで来た現状はゼロってのは難しいですね。

・社長SI比率を売上の10%以下に

>これは今年こそは実現したいです。月150万位に抑えて、全体の売上が15Mをコンスタントに出せる感じを目指します。
>そして、全体に目が届くようにして快適・スムーズに業務が回るように整理する時間を取りたいです。
これはほぼ達成ですね。今年は1千万をちょっと切るのでは無いかと思います。
今後はマーケティングと売上拡大、社内体制の整備、新規事業立ちあげに注力したいと思います。

・スマセルの新規事業の立ち上げ

>まだ発表できませんが面白いのを企んでます。収益化は来年になると思いますが、今年とにかく話題にはなるように。
一応、9月に進学コムを立ちあげました。
が、現状利用者数もなかなか伸びず苦戦している状況。
何とか今年は打開していきます。

・ダイビング事業の単体黒字化

>現地サービス等の新企画もあるため、何とかなるのではと遂に目処が立って来ました！！！
こちらについては完全に失敗。。。今年こそ。。。

・外食事業の立ちあげ

>今年こそは夢の外食事業を立ちあげたいです。秋頃には！
無理でした。

■本年の目標

・GCP（Google Cloud Platform)の業務システム開発No1の座を確固たるものにする！

昨年のGoogleのクラウドプラットフォームの拡張に伴い、目標を少し大きくしました。
GAEについてはほぼほぼ固い状態になってきたこともありますし、そちらを確固たる状態にするたみにも、
GCP全体としてのサポート体制は必須と思います。
GCEについても事業として立ちあげ、AWSからの移行サービスも立ちあげます。

・売上2億！人員20名！

これは昨年と同じになってしまいましたが、今年はある程度固いレベルで持っていく予定です。

・定常の粗利を30%に

保守、ライセンス売上が現状相当低いため、経常が安定しない状態が続いてます。
来年末までにはそのぐらいになるように持って行きたいと思います。
そのためには、既存顧客を大事にしつつ、繋吉の拡販と保守を頂ける開発を取ることを優先して行きます。

・スマセルの黒字化

これは上記にも関連しますが、進学コム事業がうまく行かないことにはこれまでの投資も無駄になってしまうので、
何としてもスマセルの黒字化を必達します。

・ダイビング事業の単体黒字化

引き続き、です。

・新規事業の立ちあげ

新規でスポーツ関連で事業立ちあげを考えてます。
今年はこちらをやりたいので、一旦飲食は諦めます。
来年こそは飲食を始められるように頑張りたい。。。。

以上です。

プライベートの方はここに書くんじゃなくて、G+の方に書きました。

色々仕事も課題がありつつも、今年は景気向上に乗って良い年にしたいと思います！
本年も皆さん宜しくお願いします！