めもめも

このブログに記載の内容は個人の見解であり、必ずしも所属組織の立場、戦略、意見を代表するものではありません。

OpenStackユーザーのためのGoogle Cloud Platform入門（パート１）

前置き

これは、GCPの公式文書ではありません。公式ドキュメントについては、公式ホームページを参照ください。

・Google Cloud Platform

実際に試してみたい方は、60日の無料トライアルをお試しください。（クレジットカードの登録が必要ですが、トライアル終了後は明示的に課金設定を行わない限り、勝手に課金されることはありませんので、ご安心ください。）

cloud.google.com

GCP（Google Cloud Platform）の基本的な整理

GCPは、Googleが提供する（Google Appsとして提供するSaaS製品を除く）クラウドサービスの総称で、「コンピュート」「ストレージ」「ビッグデータ」などのカテゴリー別にサービスが提供されています。たとえば、「コンピュート」と「ストレージ」のカテゴリには、次のようなサービスがあります。

コンピュート
サービス 説明
App Engine スケールアウト型Webアプリケーションの実行環境
Compute Engine 仮想マシンの実行環境
Container Engine Kubernetesをベースとしたコンテナ実行環境
Cloud Functions イベントドリブンの非同期処理の実行環境
Networking 上記のサービスに共通のネットワークインフラを提供
ストレージ
サービス 説明
Bigtable HBase互換の分散KVS
Cloud SQL フルマネージドサービス型のMySQL
Cloud Datastore 独自のNoSQLデータベース
Cloud Storage オブジェクトストレージ

この他に各サービスに対して共通の認証＆アクセス制御機能として、IAM（IDENTITY & ACCESS MANAGEMENT）が提供されています。また操作環境として、REST API、SDK（gcloudコマンドをはじめとするCLI）、Cloud Console（Webポータル）が利用できます。

OpenStackとの対比でいうと、ざっくり下記の対比となります。

OpenStack GCP
Keystone IAM
Horizon Cloud Console
Nova, Glance, Cinder Compute Engine
Neutron Networking
Swift Cloud Storage

リージョンとゾーンの構成

OpenStackの場合

OpenStackでは、複数のロケーションにまたがるクラスターを構成する場合、1つのコントローラーが管理するクラスターを「リージョン」として定義します。また、１つのリージョン内に複数の「アベイラビリティゾーン」を定義して、コンピュートノードやストレージ装置などの物理的なリソースをグループ分けすることが可能です。アベイラビリティゾーンをどのように分けるかは、インフラの設計次第ですが、典型的には、ラック単位で分割する、データセンター単位で分割するなどがあります。

ただし、同じリージョンに属するアベイラビリティゾーン間は、ある程度のネットワーク帯域が確保されている必要があります。1つのコントローラーが管理するクラスターは、同一のデータセンターに配置するというのが現時点でのベストプラクティスとなります。

GCPの場合

GCPでも同様に、「リージョン」と「ゾーン」によってリソースの物理配置が決定されます。2016年7月時点では、全世界に4箇所のリージョンがあり、それぞれのリージョンに複数のゾーンが用意されています。

参考：
・Google Cloud Platform: Regions and Zones
https://cloud.google.com/compute/images/zones_diagram.svg
同一のリージョンに属するゾーンは専用線による高速ネットワークで接続されており、ゾーン間とゾーン内でほぼ同等の帯域・遅延を実現しています。したがって、クラスター型のアプリケーションを複数ゾーンにまたがってデプロイすることも可能で、複数の故障区域にまたがった高可用性を実現できます。
参考：
www.apps-gcp.com

また、2016年後半には、東京リージョンの運用が開始される予定になっています。

・Google Cloud Platform に 2 つの新リージョンが追加、今後 10 リージョンがさらに追加予定

BigtableやCloud Storageなどのマネージドサービスについては、リージョンを指定して利用する（自動的に複数ゾーンで負荷分散する）方法とゾーンを指定して利用する（特定ゾーンのリソースのみを使用する）方法があり、指定可能な方法は、サービスによって異なります。詳しくは、下記のドキュメントを参照してください。

cloud.google.com

次回予告

パート2では、NeutronとNetworkingの比較を行います。

enakai00.hatenablog.com

GCPでJupyterを利用する方法

GCEのVMインスタンスを利用する場合

Dockerのコンテナイメージを利用して、Jupyterの環境を用意します。TensorFlowなど関連モジュールを導入済みのイメージをDocker Hubで公開してありますので、これを利用することができます。

※ GCP公式イメージではありません。筆者が個人的に作成したものです。イメージ作成用のDockerfileは、下記で公開しています。

github.com

CentOS7のVMインスタンスを起動してログインした後、rootユーザーから、次の手順でコンテナを起動します。

# yum -y install docker
# systemctl enable docker.service
# systemctl start docker.service
# mkdir ~/data
# chcon -Rt svirt_sandbox_file_t ~/data
# docker run -itd --name jupyter -p 8888:8888 -p 6006:6006 -v ~/data:/root/notebook -e PASSWORD=hogehoge enakai00/jupyter_tensorflow:latest

「-e PASSWORD=」には、Jupyterにアクセスする際のパスワードを任意に指定します。ただし、通信経路の暗号化は行われないため、インターネット経由で直接にアクセスするのは危険です。SSHのトンネル機能を用いて、通信経路の暗号化を行ってください。

たとえば、Windowsクライアントの環境であれば、TeratermなどのSSH端末から、次のように8888番ポートと6006番ポートの転送を指定して、SSH接続します。

Mac OS X、もしくは、Linuxクライアントであれば、次のように、-Lオプションでポート転送を指定してSSH接続します。

$ ssh -L 6006:localhost:6006 -L 8888:localhost:8888 -i .ssh/gcp_enakai enakai@xxx.xxx.xxx.xxx

この後、ローカルのブラウザーから、「http://localhost:8888」にアクセスするとSSHトンネルを経由して、Jupyterに接続することができます。

また、TensorBoardを使用する際は、Jupyterのコンソール画面からTensorBoardを起動した後に、「http://localhost:6006」にアクセスします。

Google Cloud Datalabを利用する場合

（2016/08/15 追記）
Cloud Datalabのアーキテクチャーが新しくなって、ローカルのDockerとGCP上のDockerを使い分けることができるようになりました。利用手順は、下記のWebサイトを参照してください。

・Google Cloud Datalab - Quickstarts

古い手順も参考までに残しておきます。

cloud.google.com

Cloud Datalabは、Jupyter環境をSaaS形式で提供します。バックエンドは、Google App Engine Flexible Environmentになります。上記のリンクから、環境をデプロイして利用することができます。

利用開始時にGCPのアカウント認証（SSO）が行われるので、Jupyterのノートブック内からGCPモジュールを利用して、Cloud StorageやBig Queryなどのサービスを直接に呼び出すことができます。

ただし、デフォルトでは、バックエンドのVMインスタンスのサイズが小さいため、大量のメモリーを必要とする処理が実行できません。VMインスタンスのCPUコア数やメモリー容量を指定する方法は、下記のドキュメントを参照してください。

・Customizing your Cloud Datalab deployment

たとえば、次のURLから環境をデプロイすると、n1-standard-4（vCPU x 4、メモリ 15 GB）のインスタンスが使用されます。

・http://datalab.cloud.google.com?name=datalab01&cpu=4&memorygb=14

この場合、デプロイした環境には、「datalab01」という名前が付いているので、利用する際は、下記のURLからアクセスする必要があります。

・http://datalab.cloud.google.com?name=datalab01

Cloud Datalabでは、TensorFlowも利用することができます。ただし、ビジュアライゼーションツールのTensorBoardは使用できません。TensorBoardを使いたい場合は、次に説明する方法を用いるのがよいでしょう。

※ Cloud Datalabは、現在ベータ版として提供されています。今後、利用方法など、サービス内容が変わる可能性もありますのでご注意ください。

モンティ・ホール問題をJupyterでシミュレーション

モンティ・ホール問題とは？

[問題]

「プレイヤーの前に3つのドアがあって、1つのドアの後ろには景品の新車が、2つのドアの後ろにはヤギ(はずれを意味する)がいる。プレイヤーは新車のドアを当てると新車がもらえる。プレイヤーがドア1を選択した所、モンティはドア3を開けてヤギを見せた。

ここでプレイヤーは、ドア2に選択を変更しても良いと言われる。プレイヤーはドアを変更すべきだろうか？」


答えをいうと、プレイヤーはドアを変更した方が景品を貰える確率は高くなります。最初に選んだドアが正解の確率は 1/3 ですが、ドアを変えた場合、正解の確率は 2/3 になります。数学的な証明は、こちらにあります。

enakai00.hatenablog.com

しかしながら、数学的な証明はさておき、直感的には確率が2倍になるとはなかなか理解できず、Wikipediaによると、かつて、この問題についての大論争が巻き起こったそうです。数学的な証明を抜きにして、この結果を納得する方法はないのでしょうか？



・・・・・・・


そんな時に役に立つのが Jupyter です！


Jupyterを使えば、このゲームを乱数でシミュレーションするのは、ほんの数行のコードでできてしまいます。シミュレーションを用いて、10000回ぐらいこのゲームをプレイして、勝率がどの程度になるかを実際に確認すれば、ケチのつけようのない答えが得られます。

というわけで、やってみました。

ドアを変更しない戦略の場合、勝率は、0.338 でした。一方、ドアを変更する戦略の場合、勝率は、0.666 です。確かに勝率は2倍になっていることがわかります。このコードに記載されたロジックをじっくり考えると、ドアを変更した方が「当たり」になる確率が高くなる理由も分かってくるのではないでしょうか？