読者です 読者をやめる 読者になる 読者になる

Google Compute Engine における概念のまとめ

Google Compute Engineについて利用する機会ができたので、関連する概念の概要をまとめておこうと思います。

主に用語とその簡単な概要みたいな形になるかと思います。

Google Compute Engineとは

Google Compute Engine(以降GCE)は、Google Cloud PlatformのIaaSサービスの1つです。

GCEはKVM(Kernel-based Virtual Machine)とcgroupsを利用したLinux仮想マシン、およびWindowsベースの仮想マシンを提供し、以下の方法でその仮想マシンの管理を行うことができます。

  • Developers Console (Web管理画面)
  • gcloud コマンド
  • API

料金について

料金としては、概ね以下に対する利用時間で計算されます。

  • 使用中の仮想マシンが使用する vCPU の数とメモリ(およびGPUとイメージ)
  • 永続ディスク
  • リージョン
  • 静的に割り当てられた未使用のIPアドレス
  • 継続割引

料金についての詳細は以下を確認してください。

Google Compute Engine の料金  |  Compute Engine ドキュメント  |  Google Cloud Platform

料金計算については、料金計算ツールも提供されているのでそちらも合わせて利用できます。

Google Cloud Platform 料金計算ツール  |  Google Cloud Platform

全体像

f:id:naokirin:20170409155945p:plain

インスタンス

GCEにおいてメインになるのが、インスタンスです。

インスタンスとは、Googleのインフラストラクチャがホストする仮想マシンのことです。

基本的にはGCEで作成できる仮想マシンのことになります。

仮想マシンインスタンス仮想マシンインスタンスなどと呼ばれます。

マシンタイプ

インスタンスで利用できる、ハードウェアリソースの種類を指します。

一般的には、GCEに最初から定義されているマシンタイプを利用することが多いですが、独自に定義することもできます。

マシンタイプには主に以下のリソースが定義されています。

  • 仮想CPU数
  • メモリサイズ
  • 永続ディスク容量

イメージ

イメージとは、オペレーティング システム イメージのことを指し、インスタンスはこのイメージを使用してルート永続ディスクを作成します。

イメージは、公開イメージと非公開イメージがあります。

公開イメージはドキュメントに一覧が記載されています。

Images  |  Compute Engine Documentation  |  Google Cloud Platform

非公開イメージは、必要に応じてプロジェクト単位で独自に作成・利用することができます。

ストレージ

インスタンスには、オペラ−ティングシステムをルート永続ディスクが1つと、追加のディスクを準備することができます。

ストレージの種類には以下の4つが準備されています。

  • 永続ディスク(HDDおよびSSD
  • ローカルSSD
  • Cloud Storage バケット
  • RAM ディスク

それぞれの特徴については以下で確認できます。

Storage Options  |  Compute Engine Documentation  |  Google Cloud Platform

ネットワーク

GCEでは、プロジェクト単位で複数のVPNを持つことができます。

すべてのインスタンスはプロジェクトのVPNの1つに所属することになります。 デフォルトでは"default"と呼ばれるVPNが使用されます。

内部・外部問わず、他のホストとの通信はゲートウェイを経由するL3で行われます。 L2前提の場合には注意が必要です。

ちなみにVPNはゾーン、リージョンをまたいで設定することができます。(VPNは本来そういうものですが)

外部IPアドレス

外部IPにはインスタンス起動時に動的に割り当てられるエフェメラルIPと、停止中も保持できる静的IPがあります。

エフェメラルIPはインスタンスが停止すると揮発しますが、料金が発生しません。

静的IPはそのIPを使用中のインスタンスが停止していると、料金が発生します。

DNS

VPNには、他の用途と兼任のDNSサーバが2台用意されます。

1つがメタデータサーバ、もう1つがゲートウェイです。

メタデータメタデータサーバ

GCEにはメタデータという概念があります。

メタデータはプロジェクトやインスタンスに関する情報を指し、VPN内に1台用意されるメタデータサーバに保持されます。

メタデータには以下のようなものがあります。

メタデータサーバはVPN内で一意のアドレスでアクセスできるようになっています。また、インスタンスからであれば認証なしでアクセスすることができるようになっています。

メタデータサーバにはWeb APIでアクセスできるため、特殊なクライアント等を用意する必要なくメタデータを取得することができます。

またカスタムメタデータは既存のメタデータ以外のデータをKey-Value形式で保存することができます。

メタデータサーバは更新検知機能も備えているため、メタデータの更新を利用したデプロイフローなども可能になっています。

リージョンとゾーン

Google Cloud Platformには、リージョンとゾーンと言う概念があります。

リージョンとは、リソースを実行できるGoogleのデータセンターのある各地域を指しています。 主に地理的分散やルーティングドメイン用に用意されています。

ゾーンは、リージョン内における物理的に独立した各システムを指します。 主にフォールトトレランス用に用意されています。

https://cloud.google.com/docs/images/overview/regions-zones.svg 引用元: https://cloud.google.com/docs/overview/

Google Cloud Platform において、リージョンとゾーンは以下のドキュメントにまとめられています。

地域とゾーン  |  Compute Engine  |  Google Cloud Platform

ゾーンは、GCEインスタンスの作成時などにユーザが指定することができます。

ゾーンを指定できるのには、大きく以下の理由があります。

  • 地域による料金の違い
  • 提供サービスの違い
  • リソースの分散による障害対応
  • レイテンシの軽減

現実のサービス運用に利用する場合には、上記を考慮してゾーン選択をする必要があります。

プロジェクト

Google Cloud Platformには、プロジェクトと言う概念があります。

プロジェクトは、特定のサービスやリソース群を構築するために組織的なグルーピングをするためのものと捉えると良さそうです。

リソース等の所有権やメンバーシップ、請求等はプロジェクト単位になります。

ドキュメントを引用すると『構築するもののための組織エンティティ*1となっていますが、わかるようなわからないようなという感じです。

GCEのインスタンス等のGoogle Cloud Platformにおける使用するリソースは、プロジェクトに所属する事になります。

そのためプロジェクト全体のGCEインスタンスに対しての権限などの設定も行えます。

プロジェクトには、以下の情報が含まれます。

  • プロジェクト名
  • プロジェクトID
  • プロジェクト番号

プロジェクトは(課金が有効になると)特定の請求先アカウントに紐付けられます。

複数のプロジェクトが1つのアカウントに対して請求をすることができます。

まとめ

この記事に書いたこと以外にも、GCEを利用する上で知っておくべきことはたくさんあるかと思います。 (大きなところではサービスアカウント、スケーリングなど)

説明自体で非常に簡略化した部分もあるため、実際の運用では気をつけるべき点も多くあるようです。

Portainerを利用して個人環境のコンテナ管理をする

Portainerとは

PortainerはDockerホストのコンテナ等の情報をブラウザで確認・操作できるツールです。

f:id:naokirin:20170219232457p:plain

知らずのうちに溜まっていくボリュームやイメージなどが視覚化されるので便利です。
またブラウザ上でコンテナにシェルでログインすることもでき、かなり快適に操作することができます。

最近、Dockerを使う際にPortainerを利用して、非常に便利だったので導入をメモ程度に残しておきます。

Portainerでできること

  • コンテナ、イメージ、ボリューム、ネットワークの状態の確認
  • コンテナの起動、停止、削除
  • イメージ、ボリューム、ネットワークの削除
  • DockerHub、ローカルのイメージからコンテナを作成
  • Dockerホストの状態の確認

Mac(docker-machine)の場合

現在のdocker-machineの状態を確認する

$ docker-machine env

export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.99.102:2376"
export DOCKER_CERT_PATH="/Users/username/.docker/machine/machines/default"
export DOCKER_MACHINE_NAME="default"
# Run this command to configure your shell:
# eval $(docker-machine env)

$ docker-machine config default

--tlsverify
--tlscacert="/Users/username/.docker/machine/machines/default/ca.pem"
--tlscert="/Users/username/.docker/machine/machines/default/cert.pem"
--tlskey="/Users/username/.docker/machine/machines/default/key.pem"

この時点で、dockerのホストマシンがなければ作成する。

portainer を起動する

以下のコマンドを叩くだけ

$ docker run -d -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock portainer/portainer

これで9000番ポートにportainerが起動する。

portainer でdockerの情報を確認する

先程のDOCKER_HOSTのIPアドレスに9000番ポートでブラウザからアクセスすれば、adminのパスワード設定画面が表示されるので、設定後に再度ログイン画面でパスワードを入力してログインする。

f:id:naokirin:20170212204652p:plain

基本的な使い方は以上。

portainer でリモートホストに接続する

複数のホストで起動している場合はリモート接続して、1つのportainer上で確認したいこともある。

その場合に、ホストがMacの場合、最初に表示したdocker-machineコマンドで確認した DOCKER_HOST と ca.pem、cert.pem、key.pemを利用してEndpointを追加する。

f:id:naokirin:20170212212211p:plain

Linux の場合

dockerd の設定をする

Linuxリモートホストに接続する場合、docker daemon(dockerd)の設定で tcp:// が設定されていない場合があるので以下のページを参考に設定してデーモンを再起動する。

http://docs.docker.jp/engine/reference/commandline/dockerd.html

あとはMacの項で書いた「portainerを起動する」から同じように実行できます。

木構造を描くアルゴリズムについて(Reingold-Tilford Algorithm)

最近、UnityでPlayable APIというものを調べる機会がありました。

その際にそのPlayableの木構造をUnity上で表示できるEditor拡張としてPlayableGraphVisualizerというものがあると知ったので軽く見ていて、「Reingold Tilford」というものが出てきて調べていたので、それをまとめておきます。

(ちなみに、PlayableGraphVisualizer - https://bitbucket.org/Unity-Technologies/playablegraphvisualizer

結論としてはこの「Reingold Tilford」は「Reingold Tilford アルゴリズム」と呼ばれるもので、木構造を階層的に“きれいに”表示するためのアルゴリズムです。木構造のグラフ表示の機能を持ったJavascriptのライブラリなどではこの単語が出てくることもあるようですが、私は初めて見ました。

木構造を綺麗に描くための手法と歴史

いろいろ調べていて、非常に参考になったのが以下のサイトでした。

続きを読む

Unityでスクリプトの一部分の処理をProfilerに表示してもらう

Unity

今日は非常に初歩的なTips的な話です。
Unityのドキュメントをちゃんと読んでれば知ってるくらいの知識、ということで。

Unityでゲームを開発していると(というよりはゲームを開発しているとよくあるとは思うのですが)、どうもダメージを食らったときにもっさりしているから軽くしよう、とかいう話が上がったりします。 このときにProfilerやスクリプトにログを埋め込んだりであれやこれやと調べたりするわけですが、Profiler上で表示される粒度が大きすぎて結局どこが問題か調べきれないといったことがあります。 この際に、Unityには便利な機能として、Profiler.BegineSample()/EndSample()があります。

続きを読む

ネットワーク周りの知識のまとめ (物理層)

ネットワーク

ネットワーク周りの知識をまとめておこうと思います。
今回は物理層だけど、無線部分とかは全然かけていないので気が向いたら書きます。。。
(ツイストペアケーブルと光ファイバーケーブルについて書くだけで結構疲れたw)

続きを読む

MySQL(InnoDB)のインデックスについての備忘録

最近、インデックスについて調べることがあったので、忘れないうちに出来る限り情報を残しておこうと思います。

ちなみにMySQLのバージョンは5.5および5.6の情報を元にしています。

続きを読む

Eric EvansのDDDを読んでます(4)

DDD 読書

今回は第6章(ドメインオブジェクトのライフサイクル)まで。

集約

集約はエンティティやバリューオブジェクトを1つのオブジェクトとみなし、扱います。 これにより関連をわかりやすくし、また不変条件を維持することで、オブジェクトの一貫性を保つようにします。

集約は小さなエンティティやバリューオブジェクトだけでは複雑化してしまう関連をシンプルにする役目のようです。また外部からのアクセスを集約のルートになるオブジェクトへのアクセスに制限することで、集約内の不変条件の維持を楽にできるようにしています。

実際のオブジェクト指向プログラミングでも、理解しやすく同時に変更されるような単位にクラスを分離していても、それらにアクセスするのはあるルートになるクラスのみで、他とのやりとりはそのルートになるクラスとしか行わないといったような設計をすることがあるのでイメージはしやすい感じがします。

ファクトリ

ファクトリは集約のインスタンスを生成し、生成されるオブジェクトに複雑な生成の責務を持たせることなく、またクライアントに集約の内部を晒すことがないようにします。

いわゆるGoFデザインパターンの生成に関するパターンに当たるタイプだと考えるとイメージできるかなと思いました。

リポジトリ

リポジトリは永続化されたオブジェクトに対して、メモリ上にあるかのようにアクセスできる方法を提供します。これによりクライアントが実際に内部でどのような永続化技術が使われているかを意識しないで済むようにできます。

またリポジトリで書かれている点で「テストで使用するために、ダミーの実装で置き換えるのが容易になる」というのも書かれていました。

第6章は各パターンはイメージしやすいものが多かったように感じました。 これ以降の章も読み進めつつ、実際の応用について学んでいきたいと思います。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)