ラベル 技術メモ の投稿を表示しています。 すべての投稿を表示
ラベル 技術メモ の投稿を表示しています。 すべての投稿を表示

2014-09-19

ブラウズ時間と回数を記録するツールを作ってみた


ChromeExtensionで、ブラウズしたページと時間を記録するツール(BrowseLogger(仮))を作成してみました。(集計はBigQueryにて)
約1ヶ月間程度自分のブラウザの挙動をロギングしたものです。(アクセス回数のトップ20)
恥ずかしいですが、公開します。

見事にトップ10の8割がgoogleですね。ちょっと以外だったのが、回数がdocsの方が多かったことです。
で、当然のようにmailの時間が圧倒的ですね。plusがfacebookを上回っているのが結構凄いかも。
ハングアウトでチャットしている時間が多かったのだと思いますが。



結構順当な結果ですねぇ。
当時丁度提案で必要だったのでサテライトさんのサイトが入ってたり、面白い。
sitesそんなにみてたような覚えがあまりないのですがねぇ。

ちなみに、これを取得するクエリはこんな感じです。

SELECT UserId, domain, count(*) kaisuu, sum(time)/1000/3600 sumtime 
FROM [tsunayoshi.bl] 
where UserId = "ayatoshi@yoshidumi.co.jp" 
Group by UserId, domain 
Order by kaisuu desc LIMIT 20;
4,5秒で結果帰ります。

これ、後は月次くらいで定期的に取得してどんな推移になるのか、調べて行けたら面白いなぁと思います。
そのうち繋吉シリーズとして製品化したいと思います。


2014-06-30

Google I/O 2014

先週はGoogleの開発者向けイベント I/Oでした。
サンフランシスコのモスコーニセンターにて、今年で3年連続3回目の参加です。
まずは雰囲気を感じられる写真から。

写真で見るGoogle I/O


こんな感じの人だかりです。

キーノートへ向かう途中に2Fを映すとこんな感じ。未だ出展者しか居ないのです。




US対ドイツ戦の人だかりです。セッションそっちのけで見てる人が相当居ました。

1日目終了後のアフターパーティです。今年は初めて(?)外でのパーティでした。雨降ったらどうするつもりだったのだろうか。。。


TANGOです。
Android Autoの説明をしてます。この説明を受けるには整理券が配られてて、ちょっと敷居が高そうだったので、諦めました。
日本人大集合にて。日本人は集まりが良いようです。一大集団に。

はい、以上、雰囲気が伝わりましたでしょうか?

I/Oの所感

去年迄は、GoogleApps APIやDriveの開発者向けのセッションやらブースやらがあったのですが、今年は見事に全く何もありませんでした。キーノートでDrive for Workについて触れられたのみ。
Chrome,Android,PhysicalWeb(Tangoやら),AutoやWearという新コンセプトがほぼ全てで。Cloud Platformが少々。という内容です。気持ちいいくらいすっきりとGoogleAppsについては何も無かったです。AppsAPIについてはもう開発者向けに伝えることは無くなったということでしょうか。まだまだ利用の実体が追いつくまでは広がって無いように思うのですが、Googleはもう先に行ってしまいます。
私はCloudPlatformメインで行ったので、片っ端からCloudPlatformのセッションとBoxトークというものには参加し、ほぼ全部見切れた感じです。(前回はCloudPlatformだけでも全量見るのは不可能でしたが)概ね、3月のパートナーサミットで予告された内容の具体的な中身が出てきたという印象が大きい感じですね。

では、中身を見て行きましょう。

Cloud Platformの新サービス

今回発表されたCloudPlatformにおける新サービス・ツール(として私が識別出来たもの)は以下の6つ。

-CloudSave API
-Cloud Debugger
-Cloud Trace
-Release Pipelines
-Cloud Monitoring(Powered by Stackdriver)
-Cloud Dataflow


Cloud Save APIは、GEO(位置情報)をまとめて保存出来るAPIだそうで。それをまとめてマップにアタッチするようなことが出来そうです。どこまで何が便利になるものなのかイマイチぴんと来ませんでした。

Cloud DebugerはGit上にソースを入れておく前提ですが、Watch Pointと呼ばれるものをソースコード上に設定すると、設定した瞬間に全インスタンスに対してWatch Pointが設定され、最初にそこに来た状態のみをスナップショットして確認出来るという機能です。スナップショットして見るだけなので、既存の状態には影響が無いのと、処理自体は止まらずに正常に終了します。したがってステップ実行のようなことは出来ないですが、メモリ・変数の状態はその場で確認出来ます。
本番環境でちょっと確認したい、というようなニーズには非常にピッタリです。良く分からないのでデバッグコードを埋めてデプロイして。。。。という作業は全く必要無くなります。これはかなり期待出来るので、是非早速社内で検証してみて、弊社開発方法論(IZANAMI)の中に組み込みたいと思います。

Cloud Traceは内部のAPIコールの内容が全部分かるというものです。ブラウザで全部見えて、各時間がどのくらいかかっているかもわかり、視覚的に見えるので、チューニングが簡単になると。

Release PipelinesはGitへのPush時に自動的にMavenだったり外部のJenkinsだったりを順番に叩くようなワークフローを定義することで、テスト環境でチェックを行い、問題なければ本番にリリースされる。というようなリリースプロセスを全自動化出来るというものです。全自動化は怖いので、承認プロセスを入れられるようにしてくれ、とお願いしておきました。

Cloud Monitoringは自動的に利用しているサービスを組み合わせたダッシュボードを生成してくれ、そこに対してアラート(メモリ利用量等)を設定出来ると言うサービスです。詳細はあまり教えてくれるセッションとか含めてありませんでした。Stackdriverとやらで出来る事を調べれば済むのかどうか、分からないです。取り急ぎTrusted Testerに申し込んでおきました。

Cloud DataflowはGoogleがここ数年MapReduceの代わりに利用して来てものだそうで。大量のデータ処理に対してのGoogleとしての最適解のようです。Logic層の実装だけに注力してくれれば、後は勝手に良きにはからっておきます。ということですが。簡単に言うと、旧来言われていたETLの各ステップについて、特定のルールにしたがって実装だけしてくれれば、後は自動的にモニタリング迄含めて全部やっちゃいますよ、と。自動スケールだったり、処理の組み換えまで含めて。未だコンセプト+αでTrusted Testerにさえなってない状態のようでしたが。これは今後押していくようですね。

以上、Google I/O 2014のCloudPlatform周りのご報告でした。







2014-06-19

スカイボックスの未来

以下の記事のように、米スカイボックスがGoogleに買収されました。
http://jp.wsj.com/news/articles/SB10001424052702303838604579627461249397026

さて、この影響ですが、記事の通り僕も非常に大きなものになる予感があります。
インターネットが知識の共有化を図るものだったと思うのですが、その上に地球上のリアルタイムの全ての上空画像が合わさる形になる、ということになる、と。。

これは相当ヤバイことになりそうです。戦国時代であればあらゆる大名が欲しがるというか、これがあれば100戦危うからずでしょう。なにせ、数キロ先から敵の動向が見えとるわけですから、半端ないです。まぁもうこれを黒田官兵衛が持ってれば全戦全勝でしょう!

インターネットが出てきた時の利用想定は実際はパソコン通信の中で過小評価されてた時代があったと思いますが、それに近い話もあるかも知れません。

例えば、株価で言うと本当に各社の発表前にこの情報が漏れることによって折込済の価格になる可能性とかがあります。小売の来場客数とかって意味では、RFIDやセンサー系の技術による小売業自身の把握だけではなく、それと同じか早く概算ででも方向性が出てしまう世の中になるってことだと思います。これらの情報にアクセスしやすいインフラとしてのGCPを押している我々としては非常に興味のある所です。Tangoプロジェクトと、この宇宙からの位置情報の組み合わせに関しては非常に大きな可能性を感じざるを得ないです。

楽しみです。GCPとのつながり含め、これから弊社は最先端のGoogleのシステム開発にこだわって行きます!

あ、結局スカイボックスにはそれ程触れてないけど。。。





2014-05-13

ChromeBookの使用感

chromebook pixel


G.W.前後は ChromeBook Pixel (3月にGoogleから貰った)のみで過ごして、その後VAIOが無料で修理されて外観新品になって帰って来たのでWindowsに戻って1週間、の所感です。

以下の点以外にはやはり特にChromeBookでの不自由感は無い。
-暗号化ファイル
 エクセルの暗号化もZipの暗号化もどちらも結構厳しい。顧客とファイルやり取りするには若干致命傷。
-Skype,Lineアプリ
 まぁ、これもその程度とは言え、他の人に皆切り替えてくれと言えないと厳しい。
-IMEがおかしくなる
 これはChromeでも同じなのですが、、何故か日本語変換が無効になってしまい、復帰しない。復帰方法はブラウザのアドレスバーに一度移動するとIMEが有効になり、また戻ると復帰している。コマンド操作の問題では無い。

逆に言うともう上記だけ、ということも言える。

むしろ、以下の点はChromeBookの方が優れていると感じた。
-早い
 やはりブラウジングとかは早いし、起動も早い。
-ウィルスソフトが動作しない
 あれ、うざいですよねやはり。Update時に再起動必要だし。
-オフライン性能
 GoogleDriveのオフライン性能は圧倒的にChromeBookの方が良いです。PC版だとオフラインで動くのはほんの僅かだけど、ChromeBookは開いたこと無いファイルとかでも意外とオフラインで開けたりする。

後、ちょっと困ったけどすぐ解決したこと。
-モニタの接続
 1200円でこれ買っちゃえば全然OKでした。
    Cable Matters 金メッキコネクタ搭載 Mini DisplayPort | Thunderbolt オス → VGA メス 変換アダプタ(ホワイト)  

-解像度
 以前の10月くらいのOSだと解像度が1048×800くらい?だったのですが、それ以降のどこかのアップデートで解像度をあげられるようになったみたいで、それなりに快適な解像度で表示可能です。
-右クリック
 これは誰でも知ってたことかも知れませんが、二本指

微妙にちょっと困ること。
-閉じた時の充電
 これはかなり個人的な話ですが、自分の携帯の補助電源としてPCを使ってますが、画面を閉じると、基本電源オフになるのですよね。VAIOだと、閉じても充電だけ出来るポートがあるので。


現状としては、オフライン性能の部分のメリットは結構大きくて。Skypeと暗号化ファイルの解決策が出来たら、メインをChromeBookにするってのもかなりの選択肢になりそう。
後、自分はあまり必要無いけど、開発系とか、マルチブラウザでの検証とかって用途ではやはりちょっと未だ。

2014-01-29

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との比較



2014-01-14

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比較した記事も参考になるかと思います。

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



2013-12-13

業務システムにおけるインフラ構築をGAEでやるとどうなるか?その1

業務システムにおいてGAEでのインフラ費用が通常(オンプレミス)より安くなる訳:その1』が一部の方に好評でしたので、調子にのって、GAEでインフラ構築するとどうなるのか、従来の構築手法との比較で記載していこうと思います。
ちょっと繰り返しになっている部分もあるかも知れませんが。ご容赦ください。
全何回になるか分かりません。

何は無くとも要件定義

まず、システム開発の要件定義からですよね、やっぱり。
で、要件定義の中ってぶっちゃけあんまりインフラ的な話が出てこないことが多いです。
明らかに厳しめなものであることがわかっているものを除き(youtubeのようなものとか、証券取引システムとか)、ですね。
このフェーズでの話はやっぱり機能要件に走りがちで、非機能要件の洗い出しまでしっかりやることは結構まれです。で、それでも特に問題ないっちゃないでした、ある程度のパフォーマンスは最低限出せることが多かったから、ですね。
このフェーズについては特にGAEでも従来の構築手法でも特に大きく変わりがないように思います。
決めなきゃいけないのは、規模感がわかるものやパフォーマンス要件、特殊要件(ラインプリンタとか内部とのIF要件とか)の確認になります。
後はGAEが決まっている場合はどれだけGAEに合わない要件を先に切っておくか、これは必要かも知れません。(後述)

当然の基本設計

さて、要件定義が終わったら当然基本設計です。
ここで大きくGAEと従来型のインフラ構築の差が出て来ます。

GAEの場合

GAEでの手法の場合、ここで大きく舵を切ります。
要件定義で定義された要件がGAEで満たせるのかどうか?をざっと見ます。

あり得そうなポイントは

-Private環境とIFが取れるか?
 →IP制限の問題とか、ポートの問題とか。まぁ最近は問題にならないでしょう。
-極端に短いTAT(ターンアラウンドタイム)が定義されてないか?
 →本来はまぁ要件定義の際に切れる場合は切っておく、です。
-特殊機器等との特殊なポートでの連携がないか?
 →最近それほど私の周りでは聞きませんが、ある場合は間に何か挟んで解決出来ないか、検討。
-セキュリティ要件
 →これも最近ほとんど問題ないと思いますが、そもそも外に出しちゃダメとかって話だとアウト。

このくらいじゃないでしょうか?
これに引っかからなければ基本的にGAEでOKってことで、後は以下くらいを決めればOKです。
-フレームワークどうする?
 →弊社の場合ほぼIZANAMI一択
-支払い方法は?
 →うちでサポート含め代行するか、顧客アカウントで支払いしてもらうか?
-外部IFがある場合はちょっと調整

以上。


従来のインフラ構築手法の場合

えー、これに対してですね。通常のインフラの基本設計はと言うと。
都合上、データセンタ(サーバの置き場所)は既存の環境に空きラックがある前提とします。それはそれで別の話なのですが、実際はそれも当然考慮が必要です。

サイジング

だいたいの処理量の概算等からサーバ規模を見積る、という作業です。
大規模の場合だと、ベンダーさんにヒアリングシートを出して貰って、回答。1,2週間待って回答が帰ってくる、修正して・・・・というのを繰り返す可能性あり。

構成設計

サイジングと合わせて、主にNW構成を検討して、既存の環境に合うように機器含めて整理。
サイジングの結果を持って、各種論理サーバを並べて行く。
上記の論理サーバを物理サーバにどうマップするか考える。
OSを何にするか考える。
MWを何にするか考える。
各MWをどのサーバに載せるか考える。バージョン、OS等の組み合わせでサポートがされているかベンダーに確認調整する。
また、上記の単純な配置からさらに、仮想化した場合のライセンスの考え方等を含めどのように配置するのがパフォーマンス上良いか、ライセンス費用的に良いか、運用上の境界の取り方として問題ないかのバランスを取って決定する。

費用見積り

上記がだいたいできたら、ベンダーさんに見積りをお願いする。
見積りには以下を含める必要がある。
-HW費用
-MW費用
-OS費用
-SI費用(HWの設置費用、OS設計・導入費用、MW設計・導入費用が必要)

上記での調整

費用見積り等をもって、各種調整を行い、出し入れを行う。まぁ、それなりの規模感だとまず一発で決まるなんてことはありませんので。。。

このマネジメント

忘れちゃイケない、上記の作業をするにあたっては他の業務要件の出し入れなどの調整含め、スケジュール調整やベンダコントロールが必要になってくるのでマネジメントが必須になります。これもコストとして上乗せになる感じです。



基本設計まとめ

いかがでしょうか?基本設計のフェーズにおいてはとんでもない作業量の差異が生じます。
これちなみに、通常のIAASクラウド(EC2など)だとHWとOSの一部の部分に関しては非常に楽になりますが、それ以外は必要になる部分です。
私の感触ですが、縦軸にレイヤ、横軸に作業を並べると以下のような区分になると思います。
設計見積導入構築テスト
MW必要必要必要必要必要
OS簡易簡易不要必要必要
HW簡易簡易不要簡易必要
NW簡易簡易不要簡易必要

ここで、「簡易」としたのはある程度簡単なGUIからの操作等で出来ようなレベルのもので。「導入」ってのはインストールする、というだけの部分で、「構築」はそれがちゃんと連携取って動くように細かい設定を行う、という意味合いです。
これ、基本的にGAEだと全部まるっとほぼ「不要」になります。

作業量=コストであり時間ですので、ここで決定的な差が生じます。
この決定的な差は運用フェーズにも引き継がれることになります。


長くなったので次は詳細設計フェーズから続けます。
今回から一応ちゃんと見出しを設定してみました。見やすくなったかしら?
頑張って表なんかも書いてしまいました。
しかし、この表、なんとスプレッドシートからコピペ一発でした!びっくり。


2013-12-06

エンジニアの技術力ってコーディングとかだけじゃ無いよね

昨日こんな酒を飲みながらエンジニア仲間の佐藤さん(仮称)と話をした雑談です。
たまにはGoogle関係無い話もしてみます。


以前一緒に仕事してた田中君(仮称)についての論評だったのですが、
佐藤さん曰く、非常に技術力があるんだけどなぁ、という評でしたが、僕的には違いました。
というか、「技術力」ってものの定義の違いかもしれませんが。

田中君は、技術力の中でもコーディング力や新しい技法やフレームワークに対する対応力は非常に優れて居ました。確かにそれだけを持って技術力が高いと言う見方もあるかも知れないのですが。
僕的には、技術力ってのはアウトプットというか他者と調整して技術自体が活かせる形に持っていかないと意味が無いのでそれも含めての技術力という考え方を持ってます。
残念ながら田中君は、狭義の技術力は非常に優れていたのですが、それを展開したり、自分が作ったものの意義を周りに理解してもらったりというところがあまり得意でないようでした。
新しいプロジェクトで使う新技術を習得して展開するというところの中で活躍してもらってたのですが、複数のオプションの中で彼の作成したものが採用されなかったということで、結果的にプロジェクトを離れてしまったのでした。

これは僕の反省でもあり、もっとうまく活かせるように出来れば良かったのになぁと言うところもあるのですが。
技術者としての能力として田中君についても、せっかくなのでもっと他の部分も伸ばせて行ければいいのになぁと思ってたんですよね。

昨日酔っ払った上でのたとえですが。仮に「計算能力」というので例えると。
暗算で四則演算がものすごい速度で出来たとしても(私もそろばんやってたのでそこそこ出来る)、国語能力ゼロだと小学生の算数も解けないんですよね。
A君が1000円持って買い物に行きました。100円払ってお釣りが・・・・って問題文があった時にそれを解釈する能力が無いとたとえ暗算で3桁×3桁の掛け算が一瞬で出来ても全く意味ありません。
同様に、「技術力」ってのもコーディングや新しいものの理解だけでなくそれを外部に伝えたり、プロジェクトの状況や達成したいことに合わせてフィットするように適用したりとか、いろんな能力が必要になってきます。

そう言った意味で、技術者の人にもコミュニケーション能力とか、国語とか英語とか、コーチングとか、デザインとか、周辺の能力も是非磨いてもらいたいなぁと思った次第。

難しいこと書いたな。。。

2013-12-04

apps-gaeのお薦めコンテンツ

さて、今回は弊社で運用しておりますapps-gae上のお薦めコンテンツをご紹介したいと思います。

EC2とGCEのDisk I/O比較
必読です!
色々なインスタンスタイプ別に調査してみました。
結構たくさんデータを取ったので、時間がかかりましたが、非常に面白いと思います。
この結果からすると圧倒的にGCEの方がお薦めと言うことになります。

Google App Engine Modules のScalingを試す
24時間までは正しく動くことを確認しました。バッチ処理等でもまぁ十分な時間動かせると言うことのようです。


たった1つのCloud SQLインスタンスで複数のWordpressを動かす
まぁ要は複数のGAE環境から1個のCloudSQLインスタンスだけを使って複数サイトをホスト出来るか、というところです。
GAE部分はある程度までは全て無料で1個のCloudSQLにだけ費用を払えば良いので、非常に安く運営出来そうです。SEO的にも良いので弊社は今後色々WordPressOnGAEでサイト展開していこうかなと思います。apps-gaeもGoogleサイツで今ひとつ見栄えとかがしっくりこないので、WordPressOnGAEにしてしまおうと思っています。

Google App Engine コンソールの小技
これはGAE使って開発されている方は必読というか、必須のツール作りました。
是非入れてみてください。

GAE負荷テスト その2「吉積情報株式会社の旧トップページ」
弊社のコーポレートサイトのトップページを無料範囲でどれだけ表示出来るか、という検証です。
結果、15万PVくらいはイケそうと言うことで。1日あたりなので大概の企業のコーポレートサイトはこちら(GAE)で良いのでは?と思います。

Datastoreモデル変更の影響調査
Datastoreのモデルにプロパティを追加、削除したりした時の挙動を詳細に調査してみてます。ちょっと難しめですので、開発を真面目に検討されてるSEの方のみ向けかなと思います。

いかがでしょうか?
結構色々と調査してます。一応目指しているのは昔非常にお世話になった、「おら!オラ!Oracle - どっぷり検証生活」です。

今後も順次記事は追加して行きますので、是非チェックしてみてください。
何かこれを調べて欲しいとかのお題もいただけると嬉しいです。

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-04-23

Windows8でChromeのタスクバー問題

非常に困ったのでメモ
Windows8で、Chromeをアクティブにしてると、タスクバーを自動で閉じるモードにしておいた場合にも端っこにポインタを持ってきてもタスクバーが出ない、という問題。
これは何故だか原因がわからず非常に面倒だった。ALT+TABとかしてアプリを切り替えてから、画面の端にポインタを持ってくる。という事をしなきゃならんかった。
Windows7まではWindowsキーでタスクバーが出てたんですが、Windows8からはWindowsキーがタイルの切り替えになるので。。。。
意味わからん、と。

で、結果として解決したっぽいのですが。
Chromeをタスクバーにピン留めしたショートカットから起動すると、同現象が発生します。
デスクトップのショートカットから起動すると発生しません。

いやぁ、これは本当に訳わからず非常に不便をしておりましたが、一応解決。Chrome以外のアプリではそんなことも起こらないんですけどね。

久しぶりの投稿で、こんなマニアックなのも良いでしょう。

今日は朝までリリース作業の立ち会いです。

2012-08-29

グーグルのクラウドリソースサービスについて


ずいぶーん、久しぶりの投稿になってしまいました。
暑すぎですね、最近。

さて、本当はGoogleI/Oに行った直後に書きたかったのですが、今更ながら充実してきたGoogleのクラウドリソース周りのサービスについてI/Oでのヒアリング等含めた所感を整理しておきます。

それぞれについて今後もう少し評価出来ればなぁと思っております。


・Google Apps Engine
もうあまり解説不要かも知れませんが、既に正式リリースからもうすぐまる1年となる、スクラッチ開発用のシステム基盤です。
ミドルウェア層まで提供されるため、開発者及び保守担当者はプログラムロジック部分のみに
注力出来、システムのTCOを大幅に下げる見込みがあると考えております。
また、スケーラビリティにも非常に優れており、利用量に変動のあるシステムにも最適。
災害対策もバッチリというものです。
唯一問題は、開発の難易度が高い(JavaやPythonを利用可能だが、癖が少しある)、
故に移植性も高く無い。という点でしょうか。
弊社ではこの開発難易度を下げるための工夫やノウハウを抱負に蓄積しております。

Google Cloud SQL
参考記事:http://www.itmedia.co.jp/news/articles/1110/07/news034.html
一言で言うと、GAEから利用可能なMySQLです。
上記のGAEにおける開発難易度の高さの大部分はデータアクセス層がJDOになっておるためなのですが、
その部分をMySQLにすることで既存システムの移行や既存の開発手法の流用を容易にするものです。
但し、GAEにおける優位性であるスケーラビリティは通常のものになります。
それ程スケーラビリティは必要無いし、既存の資産を流用したいと言う場合には良いかと思います。

Google Cloud Strage
参考記事:http://www.itmedia.co.jp/news/articles/1110/12/news061.html
こちらは、Amazonで言う所のS3とほぼ同等のサービスです。
クラウド上のNASですね。APIを経由した出し入れが可能です。
但し、GoogleDriveとの位置づけの切り分けについてはGoogle内でも混乱しているようで、
少し様子見かなぁと思っています。

Google Compute Engine
参考記事:http://www.itmedia.co.jp/news/articles/1206/29/news032.html
こちらも、Amazonで言うところのEC2と同じで、仮想マシン提供サービスです。
後発ですが、特に目立った改善点等は今のところ見受けられません。
GoogleI/Oで担当者は一応性能・価格比は自信があるとのことでしたが。
果たしてどうでしょうか?今後評価してみたい所です。

Google BigQuery
参考記事:http://www.itmedia.co.jp/news/articles/1205/02/news046.html
こちらは全く新しいサービスに思います。
既存のOLAPツールのようにメッシュに応じたキューブを事前に設計するのでは無く、
どんなクエリでもフルスキャン(全文検索を力技で行う)を毎回走らせると言う、
めちゃめちゃ男らしく潔い方針です。確かにクラウドならでは。
この方針には軽く感動を覚えました。
それでいて既存のOLAPツールと変わらない性能を出せていると思いますので、非常に面白いです。
是非素敵な活用方法で提案出来ると良いなぁと思います。

以上、簡単な一言解説でした。

弊社の今後の活用・提案方針としては、GAEをメインに据え、移植等の場合にはCloudSQLを併用しつつ、GAEで賄えない特殊な移植の場合はComputeEngineを利用し、Bigデータ活用の場合には是非BigQueryを。
CloudStorageについてはDriveとの棲み分けについて今後要検討、という所です。

もちろん、EC2では無くComputeEngineに既存パッケージを載せて運用して欲しいと言うニーズがあれば対応しますが、今のところそんなニーズも意味も無いでしょう^^;


2012-04-19

Microsoft、「.doc」「.xls」などのOfficeバイナリファイル仕様を公開:CodeZine

Microsoft、「.doc」「.xls」などのOfficeバイナリファイル仕様を公開:CodeZine:

そうそう、これ、1ヶ月前の記事ですが。
是非、これをベースにもっと互換性を高めるものが出てきて欲しいですねー。2003まででも完全対応してくれればひとまず充分!
最近やはり脱MSを狙っている方が多いと思う。

弊社でも脱MSを推しており、GoogleAppsに全部寄せる形の提案とかを行なっております。
現在試験中の繋吉ワークフローシステムは、GoogleAppsのスプレッドシートをそのまま利用して申請ワークフロー、決裁を行う仕組みとして構築してます。
これは、かなり画期的で、自由な体裁や、ドキュメントとしての利活用、全てWeb上で簡潔、のワークフローを実現出来ます。もちろん、XLS形式に落としてきて利用することも可能。
乞うご期待です。

2012-04-04

Email Settings API を使ってみた


ちょっと検証したいことがあり、GoogleAppsのメールの設定情報を変更するEmail Settings APIを使ってみました。
Send ASをAPIで指定したかっただけなのですが、実は結構出来ない事がありそうでした。
例えば、Send ASのデフォルトの名称は画面からは変えられるんですが、
APIからは無理そうです。(誰か出来るのが分かったら教えてください)
詳細はこちらのDeveloperGuideを見る感じになりますが。

動かして分かった事実を整理しておきます。
1.更新はそもそもURLが無い。
2.デフォルトのSend Asを持って来れないし、削除も出来ない。
3.その他のSend Asは削除して、作成する、事でまぁ対応出来る。
4.デフォルトは作成時に設定可能。
5.同じSend Asのアドレスで名称を変えたものを作成する実質上書きのような動作になる。

検証したコードはこんな感じです。

GmailSettingsService gss = new GmailSettingsService("hoge","yoshidumi.co.jp","myAccount","XXpwdXX"); List<Map<String, String>> saList = gss.retrieveSendAs("myAccount");
//追加のテスト List<String> users = new ArrayList(); users.add("myAccount"); gss.createSendAs(users, "テストです3", "myAccount@yoshidumi.co.jp", "", true);//      → OK // 更新のテスト// GenericEntry ge = gss.retrieveSendAsDef("myName");// ge.removeProperty(Constants.NAME);// ge.addProperty(Constants.NAME, "newName");// gss.updateSettings("myAccount", ge, "sendas");// →NG。どうも更新は対応してないっぽい。
//取り敢えず取ってきたもの表示してみる。 for (Map<String, String> sa : saList){ for (Map.Entry<String, String> e : sa.entrySet()) { System.out.println("key=" + e.getKey() + ", value=" + e.getValue()); } }

サンプルとして提供されているGmailSettingsServiceさえ作っちまえば後は簡単です。その中でやってることもそれ程難しく無いので、サンプルが無いだけかと思って作ってみましたが、URLが無いと言って怒られたので、ダメなのでしょう。


久しぶりにコーディングしたけど、やっぱ楽しいなー。なかなかついていくのが大変ですが。。


2012-01-12

Google Apps Certified Deployment Specialist合格


昨年の2月23日に公開された、表題の試験に2012年1月9日、めでたく合格しました!
恐らくGoogle社外では日本第一号と思われます。



NDAがあるので、詳しい内容は書けませんが、かなり難易度の高い問題だったと思います。
未だ英語版しかありませんし。

このブログでも一度勉強開始の記載をしましたが、それから徐々に勉強を行いまして、年明けに何とか受験にこぎつけ、途中何度もダメかもと思いながら受けておりましたが。。。

兎に角、まずはこれで日本ではトップのGoogleApps導入コンサルタントであることが証明されました。
今後はお客様にこの資格もあることで安心してお任せ頂けるようアピールして行ければと思います。

Google社内には数名取得者がいらっしゃるようですが、恐らく、日本企業では初めてでしょう!
単純にそれが楽しいです。

取得に向けては恐らく、
・導入経験5件以上(トータル1000アカウント位は)
・ネットワークの基礎知識
・コンサルタント的な思考
・英語能力(TOEIC700以上)
・単純な記憶等の学習時間50時間

あたりの条件は必須になってくると思います。
これから取得する方に向けての勉強方法なども時間があれば書きたいと思います。

いやぁ、大学受験以来18年ぶりにこんなに根詰めて勉強しましたょ。めでたい。
次はマラソンを頑張らねば。

2011-12-21

GAEとEC2

随分久しぶりです。
12月に入ってからは本当にあっという間に時が過ぎており、危うく更新を忘れる所でした。
本日は、友人の会社の5周年記念パーティに行って来ました。
150人位集まっており、弊社とは大違いだなぁと。
マズローの欲求で行くと昨年のうち(5周年)は、火事などの後で、生理とか生存がそもそも危うい状態でしたが。
今日のNさんの会社は既に親和か自我になってるなぁと本当に素晴らしいと思いました。
いや、ホント凄いなぁと思った。
来年こそはうちもぱーっとやりたいです!

さて、表題の件ですが、最近やはりもう、クラウドは既定路線なんですが、その先、そもそもEC2で良くって、GAEにする必要無いんじゃん?って意見もたまにあるので、その辺を酔っ払いながらも整理しておきます。
詳しくは別途、弊社で立ち上げるサイトに載せる予定ですが。

まず、GAEとEC2の違いとして、根本的には。
EC2はIaasで、GAEはPaasである、ということです。
これは、簡単に言うと、IaasはCPU/メモリ/HDDなどを提供するだけ、なのに対して、Paasはその上の実行環境も含めて提供する、ということになります。
極論すると、MWを提供するのかしないのか、です。
するのがPaasでしないのがIaasです。

で、GAEとEC2のメリット・デメリットですが。
一応、GAE派として、GAE側から立った視点で列挙してみます。

■GAEのメリット
-スケールし易い
 EC2はやはり自力でスケールさせるのが基本となると聞いてます。少なくともGAE程のスケールを自動で行う機構は別途構築しないと難しいでしょう。

-MWのメンテ不要
 これがダントツで大きいのですが、私はもうTomcatとかMySQLのパッチをあてるのはあまりやりたく無いです。これの意味する所は意外と大きくて、セキュリティレベルが相当高いです。

-冗長化も簡易
 EC2でも冗長インスタンスとかは作れると思いますが、所詮MWレベルの機能の組み合わせです。
 結局MySQLとかの運用の知識が必要になるので、やはりそれなりに大変です。

-キャパシティプランニングの簡素化
 全くしなくて良いとは言いませんが、足りなければ勝手に増えるアーキなので、事前にインスタンスを増やしておくとかってのは相当簡素に可能です。一応、アプリの性質に応じてインスタンス数をコントロールして課金を少なくする制御も可能ですが、気にするレベルには無いです。
 元々がRDBでは無いので、数の増大に対するインパクトが小さいのも特徴です。

-PGのみで運用可能
 ちょっと言い過ぎですが、上記に述べたメリットの最終結論の帰結として、こうなります。
 MWレイヤの考慮が全く不要になると言って過言ではなくなります。インフラ屋さん、さようなら、です。(自分もそうですが。。)
 しかし、世の中そうなるべきだと個人的には思ってます。

■GAEのデメリット(基本、反論含む)
-課金がわかりにくい
 EC2と比べるとわかりにくいとは思いますが、概ね安くなるのでは無いかと思ってます。
 弊社のWebサービスを例に、今後色々検証して情報公開して行きます。

-高額になる
 一定量以上使うと高額になる場合もあると思いますが、相当ヘビー且つ特殊な条件だと私は考えてます。そこまでCPUネックになるシステムは今の所経験上は考えにくいです。


-開発がしづらい
 ここからがキモい所ですが、弊社はSlim3を使ったり、様々な開発をベースに開発方法論を確立しております。私がACC時代含めて培った基幹システム構築に必要なノウハウも盛り込んで居るので、通常と比べても遜色ないと考えてます。

-ベンダーロックインになる
 これは唯一と言える反論が無いものになります。
 結局極端な話、将来に渡ってずっとGAEが比較的割安で在り続けるか保証の無い中で、ポータビリティ(アプリケーション自体の)が少ない作りをしてしまうことに対するリスク、です。
 これは存在しますが、Googleに限ってそれは(他よりも高い水準の価格帯に落ち着いてしまうこと)無い、と弊社は信じて進んでます。なので、敢えてベンダーロックインの方向に進んでます。これは戦略上及び好き嫌いの話なのです。NGな人は諦めてください。


と、言った所かなぁと思います。
GAEについて色々今後も書いて行きます。
初めてプレミアの課金が来た話とか、色々あるので、また。

2011-11-16

Google、ビッグデータ分析サービス「BigQuery」を一般公開 - ITmedia ニュース

Google、ビッグデータ分析サービス「BigQuery」を一般公開 - ITmedia ニュース:

これで、DWHも揃ったと言うことになるんでしょうか。

○端末
・ChromeBook
・Android
・ChromeTV

○PaaS
・GoogleAppEngine
汎用基盤として何にでも利用可能
・CloudSQL
上記と連携して動作。既存アプリからの移行にも。
・BigQuery
DWH系の構築用?

で、だいたいなにでも出来る気がします。
基盤はだいたい出揃った感じでしょうか。
後は作るのみ、ですね。頑張ります。

ChromeBook、まず、早く欲しいのと、出たら扱いたいですねぇ。

2011-11-08

Google+ Pageをつくろうとしたら、色々と大変だった件についての簡単なまとめ

本日、「Google+ ページ」の提供が開始されました。
「Google+ ページ」で、新しいつながりを

Google+のストリームも随分その話題で盛り上がっていたので、すでにご存じの方も多いかと思います。弊社でも早速に、ページを試してみたのですが、複数のユーザーでの共同編集機能がないことに気が付きました。

それならば、「管理ユーザーを作って、そのユーザーでGoogle+ ページを作ればいいじゃないか」と考えたところ、少し大変なことになったので、参考になればと思い、共有しておきます。

ちなみに、Google+ ページの作成自体は、とても簡単なので、みなさんもぜひチャレンジしてみてください。こちらのページなどが参考になるかと思います。
ビジネスで使える企業ページをGoogle+で作ろう!スタートアップガイド


大変だったのは、Google+を有効にする際に、うっかりあることをしてしまったからでした。

(1)Google Profilesに年齢を登録するときは、13歳未満だと強制的にアカウントが停止されてしまいます。


これ、Google+が一般公開された前後でも話題になっていたのでご存知の方も多いかと思いますが、Google+は13歳以上でないと使えません。「Google+」「年齢」などで検索すると、いろんなサイトが出てきます。
例えば、こんな感じです。
Google Profilesで年齢を13歳未満にすると、即アカウント停止。

今回、Google+ ページを共有アカウントで作成しようと、新しくGoogle Appsのユーザーを作って、Goolge+の利用を開始しようとしたときに、うっかり共有アカウントだからと、会社の創立記念日を登録したのが運の尽きでした。

ここに、2005年9月6日と登録してしまった…。ええ、弊社は創立6周年です。

すると、なんと言うことでしょう。こんな感じの画面が出ます。
なんともそっけない。

小さく「詳細」というリンクが書いてあるのでクリックしてみると、これまたそっけないお言葉が。

仕方ないので、色々調べてみると、
Google アカウントと年齢の要件に関するよくある質問
にアカウントを有効にする方法が書いてあるのですが、どうやってもクレジットカードでの確認画面に辿りつけない。

これは困った。Google Apps販売代理店ですので、近い将来に受けるであろう問い合わせに備えて、この機会に確認しておこうと思い、サポートに問い合わせてみました。

(2)では、間違った年齢を登録してしまった場合はどうすればいいの?


サポートに以下の内容で問い合わせてみたところ、停止されたアカウントでhttp://accounts.google.comにログインすると、先ほどの「Google アカウントと年齢の要件に関するよくある質問」ページにあるいずれかの方法で修正ができるとのこと。

Google Appsを導入いただいている企業様でも、今後Google+やGoogle+ Pageの活用は進むと思いますが、共同編集をしようとするときに意外にはまりがちな落とし穴ではないかと思います。(自分が痛い目にあっただけですが…)みなさん、ご注意ください。

今日の結論
「Google Profilesに年齢を登録するときは、13歳以上で登録しましょう」

※ご指摘を頂き、一部内容を修正いたしました。

2011-09-21

通信を保護する「SSL/TLS」の脆弱性を突いたhttps攻撃、研究者が発表へ - ITmedia エンタープライズ

これは地味にかなりやばい事になる可能性あり。
詳細が分からないけど、簡単にCookieが解読出来るとなると影響甚大だ。

取り敢えず、PublicなLANのセキュリティは途中のISPを信じる前提だとしても。
TLS1.2対応迄の間。
・どこが運用してるか分からないLANは一切使用しない。
・携帯のWiFi通信で勝手に繋がるのはNGにしておく。(少なくとも)
・WEPはやはり完全に禁止。
自宅では未だ有効だったりします。。。
特にPS3とか、Wiiとか知らずにWiFiでつなげててWEPとかでSSLだから安全ーなので、まぁ。
とかで大丈夫だったものが全部崩れる。
・最低でも直接現金化出来るようなサービスは絶対に使わない。
→モノ買える位だと現金化が面倒だから。
は必須になってくる。

マジで大変かも。。。