まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:iaas

普段 IBM Bluemix の紹介ばかりしている。ので、少し毛色の違うエントリにしてみます。IaaS と PaaS の共生というか、共存環境についてです。


IBM Bluemix をはじめとする PaaS(Platform as a Service) の特徴の1つはアジャイル性だと思っています。オンプレミス環境や IaaS(Infrastructure as a Service) の環境と比べて、目的のサーバー環境を短時間&少手間で用意できる、という点です。

もう少し詳しく説明すると、例えばこのような構成が必要なアプリケーションの実行環境を作るケースを考えてみるとわかりやすいかもしれません。


(概念図ですが)Java アプリケーションサーバーとデータベースを使って動くアプリケーションがあるとします。この図ではそれぞれが1台ずつで構成されているのですが、小規模利用であればこのままの構成で使うこともあるでしょう(A):
2015081101


この環境を IaaS で作るべきか、PaaS で作るべきか、を判断するケースは珍しくないでしょう。後述する自由度の問題もありますが、このプラットフォームの環境構築に絞って考えると、具体的には手順というか、手間は全く異なります。IaaS だと最初に用意されるのは最小限のネットワーク構成がなされた最小構成の Linux や Windows といった "OS" です。ここにログインしてネットワーク構成を変えたり、場合によってはファイアウォールの変更もした上で Java のアプリケーションサーバーを導入し、セットアップします。ここまでの手順を経てようやく Java アプリケーションサーバーとして利用可能になります。 一方 PaaS であれば、はじめからプラットフォームとして「Java アプリケーションサーバー」を選べばいいので、サーバーの稼働と同時に Java アプリケーションサーバーが使えるようになります。極端な言い方になりますが、「楽に作るなら PaaS」で「自分なりの設定をしたいなら IaaS」という感じになりますかね。どちらかいいのか、の答はケースバイケースだと思います:
2015081103


また、同じアプリケーションを大規模に利用しようとすると少し構成が変わります。ユーザーからの大量アクセスに備えてアプリケーション部分を複数台構成にする必要が出てきます。ということはそれらの振り分けを行うロードバランサも必要になります(B):
2015081102



これら (A) と (B) は同じアプリケーションを異なるお客様が利用するケースといえます。IaaS で (B) の環境を作ろうとした場合に、(A) で行った環境構築の作業をサーバー数の分だけ繰り返して行う、という必要はありません(1つ作った環境をコピーすればよい)が、ロードバランシングの設定は必要です。

一方、PaaS の場合は初めからアプリケーションサーバー目的でインスタンスを作ることを想定しているということもあり、IBM Bluemix を含む多くのケースでロードバランサが内蔵または標準装備されています。要はそもそも1台で動かすのか複数台で動かすのかの違いを意識する必要がないような提供形態になっています。


このように、アプリケーションプラットフォームの構築において、PaaS は単に「手間がかからない」というだけでなく、構成自体がアプリケーションサーバー用に最適化されていることで、同じアプリケーションでも色々なパターンでの提供にアジャイルに対応できる、という特徴があると考えています。


でも PaaS にも弱点があります。それが「自由度」です。PaaS はアプリケーションプラットフォームを提供する形態であるため、「アプリケーションサーバーのインスタンスを作る」ことに最適化されています。ただアプリケーションプラットフォーム全体の中にはアプリケーションサーバー以外の用途で使いたいインスタンスが存在しているケースもあります。

例えば「クローラー」と呼ばれるエージェント機能がその典型です。インターネットやイントラネット上の情報をかき集め、構造化してデータベースに記録して、ウェブのアプリケーションから利用できるような情報を収集する機能です。ユーザーからのリクエストに応じて動く機能ではなく、基本的には24時間365日、バックグラウンドでずっと動き続ける機能といえます。

このクローラー機能に関しては IaaS であれば何通りかの方法で実現できます。典型的なものが cron と呼ばれるスケジュールタスク機能を使って、定期的に指定のアプリケーションを実行させて、この中でクローラーを動かすことで実現できます。常に動かす必要がないクローラーに関しても、サーバーに直接ログインしてコマンドを実行すれば動かすことができるので、自由度高くクローラーを実現することができます。

一方でこのクローラー機能に関しては PaaS は不利です。もともとがウェブアプリケーションプラットフォームを便利に提供するためのサービスであり、ウェブアプリケーションサーバー以外の機能については本体だけでは提供されていないことも多くあって、なんらかの外部サービス等で補足する必要があったりします。

ちなみに IBM Bluemix の場合であれば、スケジュールされたタスクを動かす "Workload Scheduler" サービスを使うことで cron ライクな機能をランタイム内に実現することができるようになっています。なので Bluemix 環境に限ってはこのサービスを使う方法もありますが、必ずしも全ての PaaS 環境で実現されているわけではありません。また Bluemix 環境でもこのサービスの仕様にある程度は依存してしまうので、自由度の面ではやはり不利といえなくもありません。この「クローラー」機能を実装するようなケースは、PaaS のアジャイル性が不利になってしまうケースと言えます。


ただ、これらを調べていくことでクラウドプラットフォームの中での IaaS/PaaS の使い分けや共存に関するヒントが見えてくるように感じます。要は「適材適所に得意分野を任せる」という考え方です。上記のようなアジャイル性が求められる部分が PaaS で、クローリングやスケジュールタスクに関する部分は IaaS で、というのはその一例と言えます。他にも基本機能は PaaS の実装が理想であるが、一部にネットワークパフォーマンスが求められる特定処理があるケースであれば、その部分がボトルネックにならないよう、その処理はネットワークパフォーマンスの高いプラットフォーム(例えば IBM SoftLayer)を使う、という選択肢も考慮に入れるべきです。

クラウドが普通になってくると、IaaS と PaaS の共存も普通になっていくのでしょうかね。そういった際の考慮ポイントを理解するためにも、IaaS / PaaS それぞれの得意/不得意分野を正しく理解しておくことが大事になるのだと思います。


・・・で、長い前置きに続いて、ここからは宣伝です(笑)。

実はこのような内容のセミナーを9月2日(水)の SoftLayer Bluemix サミット2015 内の一講演としてさせていただくつもりです:
http://softlayer.connpass.com/event/17037/

※↑TrackE の 16:30 - 17:00 の回です


講演では IaaS と PaaS の両方を使って構築するようなアプリケーションの実例を紹介し、具体的にどのような構成が理想的なのか、というポイントをアプリケーションの特性に合わせながら考えていくような内容にする予定です。 Bluemix に限った内容ではなく、PaaS/IaaS 全般に対する内容にするつもりです。

興味とお時間があれば、是非9月2日にベルサール渋谷へお越しください。お待ちしております。

以上、宣伝でした(笑)。


 

まず最初に、今回のブログエントリは IBM Bluemix の中でも現状では承認制のベータ機能を紹介するものなので、Bluemix アカウントを持つ全ての人が使えるわけではない、ということをお断りしておきます。

ただ、それでもこの機能はこれまでの IBM Bluemix では苦手としていた自由度の高いサーバーインスタンスを作る(もはやサーバーである必要もなく、デスクトップでもいいけど)という点で大きなアドバンテージのある機能なので、既に使える人や、今後承認されて使えるようになる人向けに紹介します。


IBM Bluemix はオープンソースの PaaS である CloudFoundry をベースにしたクラウド環境です。ということもあって、これまでは「Bluemix は PaaS」と紹介することも多くありました。これはこれで間違いではないのですが、PaaS 故の得意・不得意分野がありました。例えば「アプリケーションサーバーを追加する」とか「データベースサーバーを追加する」といった目的であれば PaaS の土俵なので、IaaS 環境と比べても非常に高いアドバンテージを発揮できていました。しかし「サーバーではなくひたすらバッチ処理を実行するインスタンスを追加したい」とか「SSH でログインして必要に応じて各種ログを見たい」といった自由度の高い目的を実現しようとすると PaaS の特徴が制約となってしまい、IaaS 環境と比べて面倒に感じることもありました。

そんな中、IBM Bluemix は進化を遂げました。もともとは CloudFoundry をベースとした PaaS でしたが、今では Docker コンテナとして利用することもできます(これも承認制)し、更には今回紹介する OpenStack の VM インスタンスを作成することもできます。こうなるともはや PaaS と呼ぶことに抵抗が出てきます。IBM Bluemix は今や「CloudFoundry をベースとした IBM サービスの PaaS であり、Docker のコンテナであり、OpenStack VM の IaaS でもある統合クラウド環境」と説明する方が的確だと感じます(長いけど)。
2015050601


これは非常に魅力的なクラウド環境です。例えばアプリケーションサーバーは Docker のコンテナ資産として用意されているものを流用しながらバックエンドサービスで IBM のコグニティブ(認識型人工知能)サービスを使ったり、あるいはアプリケーションサーバーは OpenStackVM で自由にミドルウェアや管理機能を導入してパブリッククラウドを構築した上で、IBM CastIron をベースとした統合サービスを使って社内データに安全にアクセスする機能と統合したり、といったエンタープライズクラウド環境を IBM Bluemix だけで実現することができるようにもなったことを意味しています。


前置きが長くなりましたが、今回はこの中の OpenStack VM インスタンスを生成して利用する手順を紹介します。この IaaS 的なインスタンスが Bluemix にどのように統合されているのか、といった点で、今後この機能を利用できるユーザーが増えた時の手助けになれば嬉しいです。


では改めて Bluemix 環境内に OpenStack の VM を作成する手順を紹介します。2015/05/06 現在、この機能を使うためには事前に申請を行う必要があります。そしてその申請が受け付けられた、というメールを受け取れば Bluemix 上に OpenStack VM を作成することができるようになります。この点を事前にクリアしている場合のみ以下の手順が使えるようになります:
2015050501


Bluemix にログイン後、ダッシュボードの「仮想マシン」を選択すると OpenStack の VM の状態が表示されます。この図では8つの vCPU、12GB のメモリ、11 個のパブリック IP が使える状態になっていることが分かり、この範囲内で VM を生成して利用することができます。またこの図ではまだ1つも VM が動いていませんが、生成済みの VM がある場合はこの画面から参照することもできます。ここで「仮想マシンの作成」をクリックして、今から作る VM の内容を指定します:
2015050502


VM の内容を指定する画面に切り替わります。この画面では作成する VM の OS、名前、スペック、そしてアクセス用の認証鍵を指定します。なお OS は手持ちのディスクイメージをアップロードすることも可能です。ここでは OS は CentOS 6.5、名前は dotnsf-vm1(任意)、スペックは m1.small(CPU * 1、メモリ 2GB、ディスク 10GB)を指定しました。最後に認証鍵を新規に追加します。Secret Key と書かれた箇所の下の "+Add Key" 部分をクリックします:
2015050503


ここで認証に使う鍵をインポートして追加します。こちらで紹介した方法などであらかじめ鍵ファイルのペア(秘密鍵と公開鍵)を用意しておきます。"Add Key" 画面で "IMPORT" を選び、Key Name に鍵の名前を入力します。そして公開鍵をテキストエディタで開き、その中身を Public Key to import 欄にコピー&ペーストして最後に "OK" をクリックします:
2015050504


ここまでの手順が成功すると公開鍵がインポートされ、一つ前の画面に戻った時の Secret Key として、追加した鍵が選択できるようになります。インポートした鍵を選択して最後に "CREATE" ボタンで VM を作成します:
2015050505


これで指定されたスペックの VM が作成され、起動が始まります。ダッシュボード画面で少し待つと起動も完了し、IP アドレスの割り振りも完了して VM インスタンスとして利用可能な状態になります。なお IP アドレスはパブリックアドレスとプライベートアドレスの2つが割り振られますが、最初に表示されているのがパブリックアドレスです。なおこの画面からインスタンスの数を変更することも可能です:
2015050506


また左ペインの "Auto-scale" を選択するとオートスケールの設定を行うことも可能です:
2015050511


最後に作成した VM に SSH からログインしてみます。用意した秘密鍵が使えるツール(Windows であれば TeraTerm など)で VM のパブリック IP アドレスに SSH2 でログインします:
2015050507


認証ではユーザー名は ibmcloud 、パスフレーズは秘密鍵を作成した時に指定したパスフレーズ、そして秘密鍵として用意した秘密鍵のファイルを指定します。最後に OK ボタン:
2015050508


全て正しい情報が指定されていれば作成した VM に ibmcloud ユーザーで SSH ログインできます:
2015050509


この ibmcloud ユーザーは sudo 権限を持っているので "sudo /bin/sh" と実行すると root ユーザーでのシェルに切り替わります。こうなればツールのインストールも設定ファイルの書き換えも自由にできます:
2015050510


ここまでできればもう普通の CentOS インスタンスと同様です。アプリケーションサーバーをインストールするなり、データベースサーバーをインストールするなり、X Window と VNC サーバーを導入してリモートデスクトップ環境にしたり、自由な目的で使えるインスタンスが Bluemix 内に生成できました!


今回は Bluemix 上に仮想マシンを生成する手順を紹介しました。Bluemix はこれ以外にも Docker コンテナを扱うこともできます。PaaS としてのリリースから1年経ちますが、いつの間にか IaaS 環境まで取り込まれていました。この進化のスピードについていくのも大変ですが(苦笑)、ますます魅力的なプラットフォームになりました。







 

Amazon EC2IDCF のサーバーインスタンスを使っていますが、どうしても気になるのはデフォルト状態ではスワップ領域が確保されていないことです:
2015020601


↑メモリは1GBで残り65MBほど。
 もうすぐメモリが足りなくなりそう、でもスワップ領域はゼロ・・・


特に高速化のために memcached とかを使うアプリを動かそうとすると、どうしてもメモリが不足しがちになります。スワップ領域がない状態で、一瞬でもメモリが足りなくなってしまうとアウトです。回避するにはなんとかしてスワップ領域を確保する必要があります。


EC2 や IDCF クラウドでは静的にスワップ領域が確保されているわけではないため、EBS などの追加ディスクを使う方法もありますが、これだとスワップ領域のために料金がかかる上、EBS は I/O にも課金されるので、スワップファイルを作る先としてはコスト的に不利です。

というわけで、インスタンスの起動時にディスクの空き部分を使ってスワップファイルを作ってスワップ領域とする、という方法を紹介します。これなら(ディスクに空きがあれば、の前提が必要ですが)ディスクを追加せずにスワップ領域を確保することができます。

具体的には /etc/rc.local あたりに以下のような内容を追加します。この例ではスワップサイズをメモリ量から動的に変更するようにしていますが、あくまで一例です。固定値を書き込んでしまってもいいと思います(青字は僕のコメント):
  :
  :
SWAPFILENAME=/swap.img スワップファイル名
MEMSIZE=`cat /proc/meminfo | grep MemTotal | awk '{print $2}'` 現在のメモリ量(KB)を取得

メモリ量からスワップ領域のサイズを決定
if [ $MEMSIZE -lt 1012293 ]; then
  SIZE=${MEMSIZE}k メモリ 1GB 以下の場合、スワップ領域はメモリサイズと同じ
elif [ $MEMSIZE -lt 2097152 ]; then
  SIZE=${((MEMSIZE * 2))}k メモリ 2GB 以下の場合、スワップ領域はメモリサイズの倍
elif [ $MEMSIZE -lt 8388608 ]; then
  SIZE=${MEMSIZE}k メモリ 8GB 以下の場合、スワップ領域はメモリサイズと同じ
elif [ $MEMSIZE -lt 67108864 ]; then
  SIZE=${((MEMSIZE / 2))}k メモリ 64GB 以下の場合、スワップ領域はメモリサイズの半分
else
  SIZE=4194304k メモリ 64GB 以上の場合、スワップ領域は8GB
fi

スワップファイルを作成してスワップオン
fallocate -l $SIZE $SWAPFILENAME && mkswap $SWAPFILENAME && swapon $SWAPFILENAME
  :
  :

/etc/rc.local は他の初期化スクリプトが実行された最後に実行される設定コマンドファイルです。なのでサービスやらの自動実行が行われた最後にこのコマンドが実行され、/swap.img というスワップファイルが作成されて、スワップ領域として動き始めます。このスワップファイルのサイズは物理メモリサイズに応じて動的に切り替わるようにしています。


これでサーバーインスタンスを再起動すると、今度は起動時に上記のスクリプトが実行され、スワップ領域が動的に作成されます。これで少し安心:
2015020602



(参考)
http://dev.classmethod.jp/cloud/ec2linux-swap-bestpractice/

 

このページのトップヘ