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

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

タグ:paas

このブログエントリは Oracle Cloud Infrastructure アドベントカレンダー 2023 に参加しています。シリーズ2の 12/03 ぶんの記事です(↓の記事内容は 2023 年 12 月 02 日時点の内容で記載しています):
2023120101


このブログで紹介するテーマは「プライベート heroku っぽい PaaS 環境を無料で作る」というものです。個人プログラマにとって無料で使える環境というのはありがたいもので、Oracle Cloud Infrastructure(OCI) の always free tier は本当に貴重な環境であります。この環境に加えて、
sslip.io
dokku
という2つの無料サービス+無料アプリを使って、自分専用の heroku っぽい PaaS 環境を構築する(ついでに GitHub Actions も併用して CI/CD 環境も用意する)、というものです。


【heroku っぽい環境】
そもそも「heroku っぽい PaaS 環境」の「heroku っぽい」 環境というのがどんな環境なのか、heroku をご存じな人であれば heroku そのものをイメージしていただくのがいいと思うのですが、ご存じない人向けに私の理解で簡単に紹介しておきます。

heroku は 2007 年に創業したクラウドサービス事業名であり、その運営会社名です。Java, JavaScript, Ruby, PHP といった各種プログラミング言語によって開発されたウェブアプリケーションを仮想コンテナ上で実行するプラットフォームを提供しています。ウェブアプリケーションに加えて各種データベースや管理・監視系サービスも併せて利用することができます。最大の特徴は PaaS(Platform as a Services) を体現するシンプルさで、手元にアプリケーションのソースコードがあれば(あるいは GitHub などのソースコードリポジトリがあれば)コマンド1つでクラウド上にアプリケーションをデプロイ/更新/スケールすることができます。"*.herokuapp.com" というアプリ公開用ドメインが提供されていて、早い者勝ちでこのドメインを使ったホスト名によるアプリケーション公開ができます(カスタムドメインを利用することも可能です)。2010 年には買収に伴う形でセールスフォース・ドットコム傘下となり、セールスフォース連携機能も強化されました。

heroku は 2022 年 8 月までは無料枠を提供していましたが、現在は無料で利用することはできません。この記事で紹介する内容は、この heroku 環境を模した(というか、ほぼそのものの)「heroku っぽい」環境を自分専用に構築する、という内容です。


【sslip.io】
自分専用の heroku っぽい環境を作る、実はこれ自体は後述の dokku を使うことでさほど難しくなく構築することができます。問題は「無料で」の部分です。肝心のサーバーは OCI の always free tier などを使うことでなんとかなりそうなものですが、選択肢が少ないのが「アプリ公開用のドメインをどうするか?」でした。

この PaaS 環境はアプリケーションを1つだけ公開するわけではなく、リソースの許す限り(今回の例だと OCI の always free tier 環境の限界まで)使うことができます。つまり "app1.domain.net" と "app2.domain.net" と "app3.domain.net" と・・・のように複数のアプリケーションをこの環境で公開することができるのです。そこでこの "domain.net" に相当するドメインが問題になります。無料のホスト名を入手する DNS サービスなどもありますが、このような heroku っぽいプラットフォームを作ろうとすると、単に1つや2つのホスト名が使える DNS サービスでは不十分で、ワイルドカード DNS("*.domain.net" というワイルドカード付きホスト名に対応した DNS サービス)を、それも無料のものを使う必要があります。

そこで今回使うのが sslip.io です。ここは無料のワイルドカード DNS に対応した無料サービスなのですが、特筆すべきはその便利さです。事前のユーザー登録や設定なども不要(!)で、例えば
 XX.XX.XX.XX
というパブリック IPv4 アドレスであれば、
 XX.XX.XX.XX.sslip.io
という名前でアクセスできます。しかもワイルドカード DNS に対応しているので、
 *.XX.XX.XX.XX.sslip.io
というワイルドカードホスト名を(無料で)使うことができます。まさに今回のテーマのための神サービス! この sslip.io を使って PaaS 上にデプロイした各アプリケーションにホスト名でアクセスすることができるようになります。


【dokku】
そして dokku です。オープンソースの PaaS 環境は数あれど、構築や運用がここまで簡単なものは他にないと思っています(その代わり1サーバーで全環境を構築することになります。複数サーバーを束ねて PaaS 環境を作るのではなく、1サーバーだけのシンプルな構成で構築します)。

dokku 自体が「プライベート版 heroku」という代名詞で呼ばれることもあり、heroku と非常に似たインターフェースを持っています。dokku 本体が docker を内蔵しており、デプロイした各アプリケーションやデータベースは全て docker コンテナとして稼働します(docker コマンドを使って構築・運用するわけではありませんが、docker コマンドでコンテナの様子を確認したりもできます)。

また多くのプラグインも公開されており、例えば今回も使う Let's Encrypt プラグインを使うことでウェブアプリケーションを SSL 証明書に対応させることも(https アクセスに対応させることも)可能です。


これらのサービスやソフトウェアを組み合わせることで heroku っぽい PaaS 環境を無料で構築していきます。


【前提準備】
以下の構築作業に入る上での事前準備として、以下の準備までは完了しているものとします:

・OCI アカウント取得
Ubuntu ベースの always free tier インスタンスの作成
・同インスタンスへの SSH ログイン
・同インスタンスへの TCP 80 番ポート、および TCP 443 番ポートの解放

重要な点として、always free tier インスタンスは CentOS ベースではなく Ubuntu ベースのもの(デフォルトユーザー名が opc ではなく ubuntu のほう)にする必要があります。CentOS の場合、dokku の標準インストーラーではインストールすることができません。なんか色々工夫することで dokku インストール自体はできるようになるかもしれませんが、インストール後の運用手順とかにも影響ありそうなので、今回の記事では対象外とします。

また今回の作業の最終結果として構築する PaaS 環境ではデプロイされたウェブアプリケーションに 80 番(http)および 443 番(https)ポートで接続することになります。したがって Ubuntu 側もこれらのポートにアクセスされる想定でファイアウォールを準備しておく必要があるのでした(デフォルトでは OCI のサブネットと Ubuntu の ufw の両方が閉じられています)。この辺りはこちらの記事が参考になると思います(私も参考にさせていただきました):
Oracle Cloud(OCI)でポートを開放する方法


前提準備がそろった所で dokku を使ったプライベート PaaS 環境の構築を行います。


【dokku 環境構築作業手順】
SSH で対象の Ubuntu サーバーにログインします。以下、しばらく CLI での作業になります。とりあえずお約束のリポジトリ更新コマンドを実行しておきます:
$ sudo apt update -y && sudo apt upgrade -y

dokku はインストール用のスクリプトが提供されているので最初にダウンロードします:
$ wget -NP . https://dokku.com/bootstrap.sh

sudo を付けてインストールスクリプトを実行します。その際にバージョン番号(2023/12/02 時点での最新バージョンは v0.32.3)を指定します:
$ sudo DOKKU_TAG=v0.32.3 bash bootstrap.sh

このインストール作業は結構時間がかかります(docker のインストールや初期状態で必要なイメージのダウンロードも含みます)。作業が完了してプロンプトが戻るまでしばらく待ちます(ネットワーク次第ですが 10 分前後?)。

インストールが完了したら dokku にドメインを設定します。今回使う always free tier の Ubuntu サーバーのパブリック IP アドレスが XX.XX.XX.XX であったとして、以下のコマンドを実行します(XX.XX.XX.XX 部分を実際の IP アドレスに替えて実行してください):
$ dokku domains:set-global XX.XX.XX.XX.sslip.io

次に秘密鍵と公開鍵を dokku に登録します。dokku は dokku 自体が git リポジトリを内包していて、この内包 git リポジトリを使ってアプリケーションをデプロイするのですが、その際に利用する鍵ペアを登録する必要があるのでした。お持ちの鍵ペア(秘密鍵ファイルと公開鍵ファイル)があればそれを使うこともできるのですが、後述する CI/CD 機能のため「パスフレーズのない鍵ファイル」を用意することをお勧めします。ここではパスフレーズのない鍵ファイルを作成する手順を紹介します。

以下のコマンドを実行します。実行直後に作成する鍵ファイル名が表示されるので(特に変更の必要がなければ)そのまま Enter キーを押してください。次にパスフレーズの入力を求められますが、今回は何も指定せずにそのまま Enter キーを押してください(再度同じパスフレーズの入力を求められた時もそのまま Enter):
$ ssh-keygen -t rsa

Generating public/private rsa key pair.
Enter file in which to save the key (/home/ubuntu/.ssh/id_rsa): ←[Enter]キーを押す
Enter passphrase (empty for no passphrase): ←パスフレーズを入力せず [Enter] キーを押す
Enter same passphrase again: ←もう一度そのまま [Enter] キーを押す
Your identification has been saved in /home/ubuntu/.ssh/id_rsa.
Your public key has been saved in /home/ubuntu/.ssh/id_rsa.pub.

この操作が完了すると /home/ubuntu/.ssh/ フォルダ内に秘密鍵(id_rsa)と公開鍵(id_rsa.pub)の2つが作成されます。念のためパーミッションを 400 に変更しておきます(デフォルトでそうなっていると思いますが、念のため):
$ chmod 400 ~/.ssh/id_rsa*

これで dokku で使う秘密鍵ファイルと公開鍵ファイルが用意できました(既に所有していた鍵ファイルを使う場合はここから)。

まず以下のコマンドを実行して秘密鍵を登録します:
$ eval "$(ssh-agent)"

$ ssh-add -k ~/.ssh/id_rsa

続いて以下のコマンドを実行して公開鍵を dokku に登録します:
$ cat ~/.ssh/id_rsa.pub | sudo dokku ssh-keys:add admin

dokku 自体の環境構築はこれでほぼ完了していますが、ついでに前述の Let's Encrypt プラグインも導入しておきます。以下のコマンドを実行してください(2つ目のコマンドは Let's Encrypt で SSL 鍵を作る際に必要なメールアドレスの指定です):
$ sudo dokku plugin:install https://github.com/dokku/dokku-letsencrypt.git

$ dokku config:set --global DOKKU_LETSENCRYPT_EMAIL=(自分のメールアドレス)

ここまでの作業で dokku のインストール/セットアップは完了しました。


【アプリケーションをデプロイ】
dokku の動作確認の意味も含めて、この状態で一度ウェブアプリケーションをデプロイしてみましょう。自分で使ってみたいアプリケーションがあればそれを使っていただいてもいい※のですが、特にない方は私のアプリを使ってみてください(一応 Node.js で作られていますが、単にメッセージを表示するだけの本当にシンプルなウェブアプリケーションです):
https://github.com/dotnsf/simpleweb


※自作のものなど、他のアプリケーションを使っても構いませんが、この段階ではデータベースなどを併用しないものを用意してください。


まずはアプリケーションのソースコードを入手します。改めて Ubuntu の CLI で以下を実行してソースコードを git clone してください(自分のソースコードを使う場合は自分のコードの URL を指定してください):
$ cd

$ git clone https://github.com/dotnsf/simpleweb

$ cd simpleweb

このローカルリポジトリに dokku 用のオリジンを追加します(localhost の git を使って dokku という名前で simpleweb のオリジンを作成しています):
$ git remote add dokku dokku@localhost:simpleweb

このオリジンからデプロイする先のアプリケーション(simpleweb)を dokku 環境にあらかじめ追加しておきます:
$ dokku apps:create simpleweb

では実際にアプリケーションをデプロイします。git コマンドで作成したオリジンに push することで dokku 内へのデプロイが実行される仕組みが提供されているので、デプロイ作業は単に目的のオリジン(dokku)へ main ブランチを git push するだけです(秘密鍵にパスフレーズが指定されている場合はここで入力を促されるので正しいパスフレーズを入力してください):
$ git push dokku main

git push 実行後にデプロイが開始されます。ここではソースコードの内容からプラットフォーム環境(この simpleweb アプリの場合は Node.js 環境)を特定し、このプラットフォーム向けに docker コンテナイメージが作成され、そのイメージが dokku 内の docker コンテナとしてデプロイされることで完了します(というわけで、他のコマンドと比較して長い時間(約1~2分)がかかります):
2023120102


無事にデプロイが完了したら、最後にポート番号のプロクシ設定をします。この simpleweb アプリケーションは 8080 番ポートで稼働するよう作られているので、80 番ポートから 8080 番ポートに転送してアクセスできるよう設定します:
$ dokku proxy:ports-add simpleweb http:80:8080

2023120103


これで simpleweb アプリケーションが 80 番ポートで公開されているはずです。ウェブブラウザを起動して、
  http://simpleweb.XX.XX.XX.XX.sslip.io/
にアクセス("XX.XX.XX.XX" は Ubuntu サーバーの IP アドレス)し、以下のような画面になることを確認してください。このような画面が表示されれば成功です。dokku が正しくインストールされ、アプリケーションもデプロイできて、sslip.io を使ったホスト名での(HTTP による)アプリケーションアクセスができることが確認できました:
2023120104


ついでに HTTPS アクセスを有効にしましょう。コマンドラインで以下のコマンドを実行します:
$ dokku letsencrypt:set simpleweb email (自分のメールアドレス)

$ dokku letsencrypt:enable simpleweb

2023120105


ここまで正しく実行した上でウェブブラウザをリロードすると(TSHS が有効になっているので)自動的に HTTP から HTTPS に切り替わり、https アクセスで同じ画面が表示できるはずです(もちろん直接 https://simpleweb.XX.XX.XX.XX.sslip.io/ にアクセスしても同じ結果になります):
2023120106


【CI/CD】
最後に Github Actions を使った CI/CD 環境の構築手順についても紹介しておきます。GitHub でバージョン管理しているソースコードが更新されたタイミングで自動的に dokku 上のアプリケーションを最新ソースコードのアプリケーションに更新する、というものです。

まずは GitHub 上に管理対象のソースコードリポジトリを用意します。プライベートリポジトリでもパブリックリポジトリでもどちらでも構いません。以下では https://github.com/dotnsf/web-app-test というリポジトリを使った例を紹介しますが、実際に試す場合は実際の(自分が開発者としてアクセスできる)リポジトリを使ってください:
https://github.com/dotnsf/web-app-test


そしてそのリポジトリを使って上述のアプリケーションデプロイ手順を実行しておきます。つまり一度手動でオリジンを追加(git add remote origin)して、アプリケーションを作成(dokku apps:create)して、デプロイ(git push dokku main)して、HTTPS アクセスを有効(dokku letsencrypt:enable)にしておき、アプリケーションに HTTPS アクセスができる状態を作っておきます:
2023120105


この状態から CI/CD 環境を構築していきます。まずは GitHub Actions を定義するのですが、手始めに秘密鍵を登録します。GitHub の該当リポジトリで "Settings" メニューを選択します:
2023120107


"Settings" 画面の左メニューから "Secrets and variables" - "Actions" を選択します:
2023120108


秘密鍵を登録したいので "Secrets and variables" 画面内の "New repository secret" ボタンをクリックします:
2023120101


秘密鍵を登録する画面が表示されます。NAME 欄には SSH_PRIVATE_KEY と入力します。また value 欄には上述の作業中に作成して使った秘密鍵ファイル(id_rsa)のテキスト内容を "-----BEGIN RSA PRIVATE KEY-----" から "-----END RSA PRIVATE KEY-----" まで)をそのままコピー&ペーストして入力し、最後に "Add secret" ボタンをクリックします:
2023120102


以下のように表示されれば、GitHub リポジトリへの秘密鍵の登録は完了です:
2023120103


次にリポジトリ内にプッシュ時に実行される GitHub Actions を定義します。そのためにソースコード内に .github/workflows/ というフォルダを作成し、その中に deploy.yml(つまり .github/workflows/deploy.yml ファイル)を以下の内容で作成します:
---
name: 'deploy'

# yamllint disable-line rule:truthy
on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Cloning repo
        uses: actions/checkout@v2
        with:
          fetch-depth: 0

      - name: Push to dokku
        uses: dokku/github-action@master
        with:
          # specify the `main` branch as the remote branch to push to
          branch: 'main'
          git_remote_url: 'ssh://dokku@XX.XX.XX.XX:22/web-app-test'
          ssh_private_key: ${{ secrets.SSH_PRIVATE_KEY }}

青字XX.XX.XX.XX は Ubuntu サーバーのパブリック IP アドレスで、赤字web-app-test 部分は(dokku apps:create した時に指定した)アプリケーション名で、それぞれ置き換えて作成してください。またソースコードの書き換えが視覚的にもわかるよう、アプリケーション側にも何らかの変更を加えておいてください。

これらのファイルをリポジトリに追加して更新します:
$ git add .

$ git commit -m 'dokku CI/CD with Github Actions'

$ git push

最後の "git push" が完了すると上記で作成した Github Actions が起動し、定義内容に従って自動的にビルド/デプロイが開始されます。デプロイの様子は Github リポジトリの "Actions" メニューから確認することが可能です:
2023120104


デプロイ完了後にアプリケーションにアクセスすると、最新のソースコードでデプロイされたアプリケーションが表示されるはずです(元のアプリで表示されていたメッセージの最後に "!" を追加する変更を加えていたのですが、正しく反映されていました):
2023120106


これで CI/CD も実現できたことになります。ソースコードの main ブランチが更新されてコミット/プッシュされるたびにアプリケーションも自動更新されてデプロイしなおされる、という便利な機能も使うことができそうでした。


【おまけ】
自分が dokku を使っていて気付いたことなのですが、どうもデプロイのたびに変なゴミというか、使われることのないファイルが残ってしまうらしく、特に CI/CD を使って何度もデプロイしていると、どんどんディスクの残り容量が減っていってしまうようでした。これを回避するには定期的に以下のコマンドを実行する必要があります:
$ docker system prune -f && docker system prune --all -f

面倒でなければ手入力でもいいと思いますし、面倒な場合は crontab にでも登録してアクセス数が比較的少なそうな時間帯に実行するのがいいと思っています。


【まとめ】
以上、無料のサービスだけを組み合わせる形で、CI/CD 含めたプライベート heroku (っぽい)環境を作ることができました。理論上はこの環境にいくつでも複数のアプリケーションを登録して、別々に運用することができる環境なのですが、さすがに always free tier の環境(メモリ 1GB ディスク 30GB)で運用することを考えると、5~6アプリが限界ではないかと思っています。もちろんこのリソーススペック上の制約は有償版を使うことで回避できます。また有償版の OCI なら DNS も使えるので(sslip.io を使う形ではなく)カスタムドメインを利用して環境構築することもできるようになります。 とはいえ、「無料で構築できる PaaS 環境」という素敵な響きにも替え難い魅力がありますよね。いずれはリッチなスペックの VM +カスタムドメインで運用するとしても、初めのうちはこの無料環境でプライベート PaaS を楽しむのも悪くないと思っています。なお(無料というわけにはいきませんが)カスタムドメインやその DNS のセットアップまで含める形で dokku 環境を作ったこともあります(OCI は全く使ってませんけど・・)。その時の内容に興味ある方は私の dokku 関連の過去の記事を参照ください。

dokku に関して、とりあえず環境構築と試験的な運用までが可能な一連の手続きについてはこのブログエントリ内で紹介していますが、実際にはこの中で紹介していない色々な機能があります(スケール対応とか、データベース系のプラグインを併用するとか、・・)。dokku はオンラインヘルプも充実しているので、詳しくはドキュメントを参照してください。

最後に注意点を。今回紹介した方法で dokku 環境を構築してアプリケーションを公開すると、事実上サーバーの IP アドレスを公開する形になります(sslip.io を使っているので、アプリケーションのホスト名の中に IP アドレスが含まれることになるからです)。サーバーの IP アドレスがバレても困らないように SSH などはしっかりセキュアに対策しておくといった対策はしっかりしておきましょう。

私自身は実際に dokku で(カスタムドメインを使って)自作サービスをいくつか運用しています。2年以上使っていますが、とても便利です。この記事が私と同じような技術クラスタの人のお役に立てれば何よりもうれしいです。


普段 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 環境まで取り込まれていました。この進化のスピードについていくのも大変ですが(苦笑)、ますます魅力的なプラットフォームになりました。







 

Cloud Foundry をベースとした PaaS 環境である IBM Bluemix が正式サービスとなり、価格も発表されました:
IBM Bluemix : Pricing Sheet

Bluemix の場合、アプリケーションサーバーと、サービスと呼ばれる(データベースとかSSOとかの)パーツとで別々の課金が行われて、利用料金という意味ではその合計になります。サービスの価格はサービスの種類によっても異なるので後述します。 で、アプリケーションサーバーの価格を見ると(2014/07/17 時点では)「メモリ1GBの仮想マシンを1時間使うと $0.07 」と設定されています。サーバーインスタンスに搭載しているメモリ量で時間課金、というタイプです。計算を楽にしたいので、仮に $1 = 100円とすると1時間7円ということになります。

ちなみに Bluemix のアプリケーションサーバーはデフォルトではメモリ512MB(0.5GB)で稼働します。つまり1時間3.5円。一ヶ月を30日とすると、1サーバーインスタンスの月額は 3.5 x 24 x 30 = 2520円です。
2014041701


このスペックをモデルケースとして、これが安いのか高いのか?、ということを考えてみます。

比較対象を「本家」の Cloud Foundry としましょう。こちらの料金体型もメモリ量での時間課金タイプですが、料金は1GBを1時間使うと $0.03 、ここだけ見ると Bluemix の半額以下です。同じ条件で512MBメモリを搭載した1サーバーの月額にすると 1.5 x 24 x 30 = 1080 円ということになります。
2014041702


とりあえず、同一条件の1アプリケーションサーバーを使った場合の料金は CloudFoundry の方が半分以下になる、ということはわかりました。ただ現実はそこまで単純ではありません。

ここまでの話はあくまで「アプリケーションサーバーの料金」です。多くの場合、アプリケーションはアプリケーションサーバー上にデプロイして動作させますが、同時にデータベースサーバーなども必要になります。

CloudFoundry の場合、データベース(例えば MySQL)サーバーを1つ追加しようとすると、アプリケーションサーバーと同一のマシンに MySQL サーバーも入れてしまう、という選択肢はありますが、さすがにメモリ 512MB で両方動かすのは無理ではないにしても厳しいと思われます。というわけでメモリを増やすとか別途データベース用サーバーを1台追加することになり、同じスペックのマシンだったとしても2台分の料金(1080 x 2 = 2160 円)が必要になります。メモリを倍に増やした場合も同額です。

一方 Bluemix の場合、データベースサーバーは「サービス」として提供されており、サービスは制約の中であれば無料で使うことも可能です。例えば MySQL は無料、PostgreSQL も無料、SQL DB(DB2) はデータ量2GB以内の1インスタンスであれば無料、といった具合です。制約といってもデータ量2GBまで使えるのであれば、結構多くのケースで無料利用ができると思っています。しかもこれらのサービスはいわば DBaaS として提供されており、Buildpackの用意やアプリケーションの導入などは不要ですぐに使いはじめることができます。つまりデータベースは(制約の中であれば)無料で追加できるオプションとなっているので、利用料金は変わらずアプリケーションサーバー代のみの 2520 円ということになります。
2014041703


この時点でもかなり差がなくなってきました。更に、例えば MongoDB などの no-SQL データベースサーバーを追加したり、データ高速化の memcached サーバーを追加したりすると、CloudFoundry ではサーバー構築の手間が増えるだけでなく、これらのサーバーを追加することになるので、もう1台、更にもう1台・・・とコストもどんどん高くなっていきます。

一方、Bluemix ではこれらのサービスも制約の中ですが無料で使える範囲が設定されています。つまりサービス用のサーバーは増えてもコストは変わらずアプリケーションサーバー代の 2520 円のままで利用することもできるのです。ここまでの環境トータルで考えると Bluemix の方が安くなっていることも珍しくないと思っています。
2014041704


だからといって Bluemix の方が得とも言い切れない所が難しいです。CloudFoundry では Buildpack を用意することで「サーバー1台で済ませる」という選択肢もあり、同一スペック1台での比較となると上記のように CloudFoundry の方が安いのです。 一方 Bluemix のサービスは無料の枠が用意されてはいるものもありますが、その枠を超えて利用する場合には有料となります。無料枠は利用するサービスの種類によっても異なるので、その辺りは設計後に正しく見積もる必要がでてきます。
2014041705


最終的にはシステム構築に必要なサーバー構成を冗長化なども含めて検討した上で選択する、ということになるのだと思います。そこまで含めても Cloud Foundry と比較した Bluemix の価格が一概に高いとは言えない(安いとも言えない)と感じています。 

ただシステム構成が複雑になればなるほどアプリサーバーの課金がメインとなる Bluemix に割安感が出てくるんだろうな、という印象を持ちました。 また比較対象を PaaS ではなく、AWS などの IaaS と比べてみても、アプリケーションサーバーとデータベースサーバーとあれとこれと・・・まで付けて月額 2530 円~ であれば充分に価格競争力もあるんじゃないかな、と思えます。


 

前回、BLUAcceleration for Cloud のインスタンスを起動して、ウェブコンソールにログインする手順までを紹介しました。その続きです:
Bluemixから提供されるDBaaS : BLUAcceleration for Cloud を使ってみる(1)

ではこの環境に実際に解析するデータを投入してみます。
データは何でもいいのですが、ビッグデータの活用に積極的で、統計情報を公開している福岡市のサイトからサンプルデータを使わせていただくことにします:
福岡市サンプルデータサイト

使うデータはどれでもいい・・・というわけではなく、対応フォーマットの中でもサンプルとして加工が楽そうな CSV ファイルにします。マップ系データの中の K01 スポーツ施設 というデータをダウンロードしてみます:
2014062101


ダウンロードファイル名は K01.csv というファイル名になっています。

で、実はこの CSV ファイルは文字コードがシフトJISになっています。BLUAcceleration for Cloud だと文字化けしそうなので UTF-8 に変更する必要があると思っています(この辺りの詳しい仕様は未確認)。開発者の方であれば何らかのツールをお持ちだと思います(僕は EmEditor で変換しました)が、K01.csv ファイルを UTF-8 に変換しておいてください。


そして、このファイルを BLUAcceleration for Cloud 環境にロードします。前回紹介した方法でウェブコンソールにアクセスします:
2014062009

画面上部のメニューから Manage - Load Data を選択します。ここから何段階かに分けてロードするデータを指定していきます:
2014062102


まずは CSV ファイルを指定します。「ファイルを選択」ボタンをクリックして、先程ダウンロード&文字コード変換した K01.csv ファイルを指定します。またその下の "Row one contains the column name(1行目は列名データ)" を ON の状態にします:
2014062103


日付時刻データが含まれる場合は Advanced Options を展開して日付・時刻のフォーマットを指定します。最後に Load File ボタンをクリックします:
2014062104


データのプレビューが表示されます(シフトJISコードだとこの時点で文字化けしているはずです)。このデータを使う場合は Next ボタンをクリックします:
2014062105


次にこのデータを格納するテーブルを指定します。既にテーブルが存在していて、その中に格納する場合は上の "Load into an existing table" を、新規にテーブルを作成してその中に格納する場合は下の "Create a new table and load" を選択します(ここでは後者を選択しています)。そして Next ボタンをクリック:
2014062106


データの内容を元に自動生成されたテーブルとその名称が表示されています。必要があればこの内容を編集して改変します(特に変更の必要がなければこのままでも構いません)。そして Finish ボタン:
2014062107


ロード結果が表示されます。この画面ではとりあえず成功して 40 行のデータがロードされた、ということがわかります(ビッグデータといえるかどうか・・・)。このデータは直前に指定した K01 テーブルに格納されているはずです:
2014062108


ロードしたデータを確認してみます。メニューから Manage - Work with Tables を選択します:
2014062109


画面左ペインのスキーマ一覧から K01 テーブルを選択すると、右ペインの K01 テーブルのスキーマが表示されます。今は K01 テーブルの中身を参照したいので、この右ペイン内の Browse Data タブをクリックします:
2014062110


K01 テーブルにロードされたデータの一覧が表示されます。このような状態にまでなっていればデータがデータベースに取り込まれて、解析のための準備ができたことになります。

この状態から各種のフィルタリングや列の表示/非表示切り替え、表示順変更などが可能になります。試しにフィルタリングを作ってみましょう。画面赤枠のフィルタリング作成ボタンをクリックします:
2014062111



フィルターの作成画面が表示されます。ここでは単純ですが、名称に「博多」を含むデータだけをフィルタリングしてみます。条件を指定して「フィルター」ボタンをクリックします:
2014062112


名称に「博多」を含むデータだけが選別されているはずです:
2014062113


本来ならばこうしてクラウドにロードされたデータに対して Cognos BI などを使って解析する、ということになると思うのですが、無料アカウントのせいなのか、どうもそこまでの権限はないようでした(与えられたサンプルデータを使う、ということはできそうでした)。残念、無料アカウントではここまでか。









 

このページのトップヘ