IDCF Tech-Blog

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

IDCF Tech-Blog

クラウド・ビッグデータ・データセンターを提供するIDCフロンティアの公式エンジニアブログ

プライベートコネクト経由でYBIにデータをimport/exportする

Yahoo!ビッグデータインサイト TreasureData クラウド

はじめに

Yahoo!ビッグデータインサイト(以下YBI)を用いて、大量のデータを容易に分析することができますが、重要なデータをインターネット上でやりとりしたくない、そもそもインターネット接続なんてさせていない、みたいなケースがしばしばあるかと思っています。

データを扱う上でセキュリティは無視できないもの、切っても切り離せない永遠の課題です。 IDCFクラウド(オンプレでも可)ではプライベートコネクトを用いて、プライベートなネットワーク上でYBIに対してデータのimport/exportを行なうことが可能です。 (プライベートコネクトというのは、プライベートでセキュアなネットワーク、いわゆるVPNと考えてください)

f:id:inoueissei:20160920112423p:plain

プライベートコネクト側の設定

プライベートコネクト側の設定はいたって簡単です。3分くらいで終わります。 まず、プライベートコネクトのコンソール画面でYahoo!ビッグデータインサイトの接続を選択し、 f:id:inoueissei:20160920145908p:plain

任意のネットワークアドレス、プライベートIPを設定します。 つまりユーザー側で好きなプライベートIPの指定が可能です。 f:id:inoueissei:20160920112524p:plain この例の設定では、YBIのAPIに対して192.168.20.1で、YBIのコンソールに対して192.168.20.2でアクセスできるようになります。

YBIではAPIエンドポイントに対してデータのimportを行います。以上でimport用の設定は完了です。

次にexport用の設定です。 exportはユーザーマシン(FTP、MySQL、APIサーバーなど)に解析データをexportする機能です。

"Result Export先Host"部分にexport先のマシンのプライベートIPアドレスを入力し、 を押すとexport用のFQDNが自動でアサインされます。 f:id:inoueissei:20160920112600p:plain この例では192.168.1.1のFTPサーバーと192.168.10.1のMySQLサーバーをexport先に登録する形になります。

以上でプライベートコネクト側の設定は完了です。

実際の利用方法

YBIのアカウント作成、マシン側のtd(CLIツール)、td-agentインストールまでは完了しているとします。 YBIの基本的な使い方はこちらを参考にしてください。

td コマンドを使用する際に、URL部分に先ほどのAPI用のプライベートIPを指定します。 (通常はybi.api.idcfcloud.netの部分) 例えば、下記はプライベートコネクト経由でnginx用のDBにtest というTableを作成しています。

td -e http://192.16.20.1 table:create nginx test

YBI側のコンソールを確認してみると、確かにnginxのDBにtestのTableが作成されています。 (このコンソール画面にも192.168.20.2のプライベートIPでアクセスできます。) f:id:inoueissei:20160920112638p:plain

td-agent側の設定は、/etc/td-agent/td-agent.conf で設定します。

 <source>
  type tail
  format /^(?<remote>[^ ]*) (?<host>[^ ]*) (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^ ]*) +\S*)?" (?<code>[^ ]*) (?<size>[^ ]*)(?: "(?<referer>[^\"]*)" "(?<agent>[^\"]*)" "(?<forwarder>[^\"]*)")?/
  time_format %d/%b/%Y:%H:%M:%S %z
  path /var/log/nginx/access.log
  pos_file /var/log/td-agent/nginx-access.pos
  tag td.nginx.test
 </source>
<match td.*.*>
  @type tdlog
  apikey 123456789012345678901234567890
  auto_create_table
  buffer_type file
  buffer_path /var/log/td-agent/buffer/td
  endpoint http://192.168.20.1   ###ここをAPIエンドポイントIPにする###
  flush_interval 10s
  <secondary>
    @type file
    path /var/log/td-agent/failed_records
  </secondary>
</match>

上記の例だと、nginxのアクセスログが、td-agentを用いて、192.168.20.1がアサインされているYBIのnginx.testにimportされていきます。当然インターネットは経由しません。

実際はこんな感じでアクセスログのデータが溜まっていきます。 f:id:inoueissei:20160920112710p:plain

YBIではデータを解析した結果を抽出するというResult Exportという機能があります。 プライベートコネクト経由でユーザーマシンにexportする際には、YBIのResult Exportの設定画面で、Hostの部分に 専用のFQDN を入れる必要があります。(※プライベートIPだと期待した動作にはならないので注意してください。)

f:id:inoueissei:20160920112734p:plain

これで適切なSQL文を書いて、実行(Run)すると、192.168.10.1 のMySQLマシンに結果がexportされます。

利用明細&ビリングAPIでIDCFクラウドの利用状況を把握しよう

IDCFクラウド API

使いたいときに使いたいだけリソースを使用できるのはクラウドの魅力ですが、無駄なく効率的に利用するためには利用状況を把握しておく必要があります。今回はIDCFクラウドの利用状況を把握するために、利用明細とビリングAPIを活用する方法をご紹介します。

利用明細を見てみよう

まずは利用明細を見てみましょう。https://console.idcfcloud.com/billing/からみることができます。 (下図のように右上のアイコンから「ビリング」を選んでも良いです。)

f:id:asasaki:20160823144700p:plain

利用明細では下図のように、各月の明細を確認することができます。 今月分については昨日までの値が反映されており、今月どのくらい使っているか確認できます。

f:id:asasaki:20160823144813p:plain

各項目をクリックするとスペックや個数など詳細な情報をみることができます。

f:id:asasaki:20160823145058p:plain

CSV形式の利用明細を活用する

各仮想マシン毎の明細を確認したい、集計方法を変えたいといった場合はCSV形式の利用明細が便利です。 CSV形式の利用明細は右上のボタンからダウンロードできます。

f:id:asasaki:20160823145329p:plain

ExcelやGoogleスプレッドシートへ貼り付ける扱いやすくなります。

f:id:asasaki:20160823145559p:plain

CSV形式の利用明細はポータル画面上よりも詳細です。ポータル画面上では表示されないリソースの表示名や作成・削除日の情報も含まれています。

CSVの各列の意味は以下の通りです。

明細画面のエクスポートCSVの各項目の意味を教えて下さい | IDCFクラウド

列名 説明
Region jp-east リージョン
ServiceName Cloud Computing サービス名(IDCFクラウド、オブジェクトストレージなど)
ZoneName newton ゾーン名
Category VirtualMachine リソースのカテゴリー(仮想マシン、ボリューム、IPアドレスなど)
Menu light.S1 商品名(仮想マシンのスペック、トラフィックの種類など)
ResourceDisplayName vm01 リソースの表示名
StartDate 2016-08-01 リソース使用量の算出開始日
EndDate 2016-08-01 リソース使用量の算出終了日
Usage 39.05944442749 リソースの使用量
Allocated 216 リソースの確保時間。単位は時間
Running 39.05944442749 仮想マシンの起動時間(CategoryがVirtualMachine以外の場合は0)
Stopped 176.94055557251 仮想マシンの停止時間(CategoryがVirtualMachine以外の場合は0)
Amount 15 税抜き請求額
Tax 1 消費税
Net 16 税込み請求額

ピボットテーブルなどで集計すると利用状況がよりわかりやすくなります。 下図はGoogleスプレッドシートのピボットテーブルで、ポータル画面と同様の表示になるようリージョン(Region)、サービス(ServiceName)、カテゴリー(Category)ごとに税抜き請求額(Amount)を合計したものです。

f:id:asasaki:20160823150258p:plain

ビリングAPI+Googleスプレッドシートで日々のリソース利用の変化を把握する

ビリングAPIで利用明細を取得する

ここまで、利用明細から各月の利用状況を把握できることをみてきました。 本項ではもう一歩踏み込んで月内でのリソース使用量・課金額の変化を調べてみましょう。

利用明細に記載されている値は月初〜月末(今月分は昨日)までの合計使用量・課金額であるため、それだけをみても月内の変化はわかりません。しかし、今月分の利用明細に昨日までの値が反映されていることから、毎日利用明細を取得すれば値の変化からリソース使用量・課金額の変化がわかります。

しかし、毎日利用明細をダウンロードしてExcel等に読み込ませるのは大変です。このように定期的なタスクがある場合はAPIを使って自動化できると便利です。IDCFクラウドには利用明細を取得するためのビリングAPIがあるので、これを使ってみましょう。

ビリングAPIを使うと、次のように指定した月の利用明細をJSON形式で取得することができます(シグネチャの生成方法などの詳細はドキュメント)を参照してください。)。レスポンスのdataの配列の中にCSV形式の利用明細の行に対応するオブジェクトが入っています。

$ curl -n https://your.idcfcloud.com/api/v1/billings/2016-04 \
  -G \
  -d format=json \
  -H "X-IDCF-APIKEY: SrE5Ceeb1Q9MPl0yM0qbd3D3_CCpLWqnbcruMBj2WyK03Q6r0l6YJhIdCsYUmB7VM8AFttoqsxc3FxQrsAh8VQ" \
  -H "X-IDCF-Expires: 1437142261" \
  -H "X-IDCF-Signature: EenNFoNxnYEQVGW279XcQ+tBgwFPpMmTkDZQvKryIZg="
{
  "meta": {
    "account_id": 71000090048,
    "billing_period_start_at": "2016-04-01",
    "billing_period_end_at": "2016-04-30",
    "invoice_no": "B7112834501",
    "taxable_amount": 43608,
    "tax": 3484,
    "total": 47092,
    "updated_at": "2016-04-07T10:03:00+0900"
  },
  "data": [
    {
      "Allocated": 42.0,
      "Amount": 42,
      "Category": "example",
      "Enddate": "2016-02-01",
      "Menu": "highio.5XL128",
      "Net": 42,
      "Region": "jp-east",
      "ResourceDisplayName": "ROOT-2622",
      "Running": 42.0,
      "ServiceName": "Cloud Computing",
      "StartDate": "2016-02-01",
      "Stopped": 42.0,
      "Tax": 42,
      "Usage": 42.0,
      "ZoneName": "tesla"
    }
  ]
}

Google Apps ScriptとビリングAPIで利用明細をスプレッドシートに取り込む

ビリングAPIの実行用に新しく仮想マシンを用意しても良いですが、今回はGoogleが提供しているスクリプト環境であるGoogle Apps Scriptを使って実行しGoogleスプレッドシートに利用明細を取り込んでみます。Google Apps ScriptはGoogleの環境上で動くので新しく仮想マシンを用意することなくビリングAPIを実行することができます。さらに、実行されていることがわかるよう実行時にSlackで請求額を通知するようにしてみます。

Google スプレッドシートでデータ取り込み用に新しくスプレッドシートを作成します。(名前は何でもかまいません。)作成したスプレッドシートを開きID(URL https://docs.google.com/spreadsheets/d/*************/edit#gid=0 のアスタリスクの部分)を控えて下さい。

SlackにはIncoming Webhooksという仕組みを使って通知を行います。Slackにログインしている状態でhttps://my.slack.com/services/new/incoming-webhook/にアクセスしメッセージを投稿するチャンネル等の設定を行って生成されるWebhook URLを控えてください。どこから通知が送信されたのかわかりやすいよう名前やアイコンも変えておくとよいでしょう。

次に、https://script.google.comにアクセスします。 空のプロジェクトが既に作成されているので、元からあるコードを消して以下のコードを貼り付けて下さい。 はじめの3行のAPIKEYSECRETSPREADSHEET_IDSLACK_WEBHOOK_URLをIDCFクラウドのAPIキー、シークレットキー(https://console.idcfcloud.com/user/apikeyで確認できます)、控えておいたスプレッドシートのID、SlackのWebhook URLに書き換えてください。

var APIKEY = "IDCFクラウドのAPIキーをいれてください";
var SECRET = "IDCFクラウドのSECRETキーをいれてください";
var SPREADSHEET_ID = "GoogleスプレッドシートのIDをいれてください";
var SLACK_WEBHOOK_URL = "SlackのWebhookのURLをいれてください";

function getThisMonth() {
  var date = new Date();
  return date.getFullYear() + "-" + ("0" + (date.getMonth()+1)).slice(-2);
}

function getToday() {
  var date = new Date();
  var this_month = date.getFullYear() + "-" + ("0" + (date.getMonth()+1)).slice(-2);
  return this_month + "-" + ("0" + date.getDate()).slice(-2);
}

// Billing APIで利用明細を取得
function getUsageData(month) {
  var query_string = "format=json";
  var expiration_seconds = 30;
  
  var date = new Date();
  var endpoint_uri = "/api/v1/billings/" + month;
  var expiration = (Math.floor(date.getTime()/1000) + expiration_seconds).toString();
  var message ="GET" + "\n" + endpoint_uri + "\n" + APIKEY + "\n" + expiration + "\n" + query_string;
  var signature = Utilities.base64Encode((Utilities.computeHmacSha256Signature(message, SECRET)));  
  var url = "https://your.idcfcloud.com" + endpoint_uri + "?" + query_string;
  var params = {
    "headers": {
      "X-IDCF-APIKEY": APIKEY,
      "X-IDCF-Expires": expiration,
      "X-IDCF-Signature": signature
    }
  }
  return JSON.parse(UrlFetchApp.fetch(url, params).getContentText())["data"];
}

// 利用明細に本日の日付を表すDate列を付加してGoogleスプレッドシートに書き込む
function sendUsageDataToSpreadsheet(ss, sheet, data) {
  var this_month = getThisMonth();
  var today = getToday();
  var keys = [
    "Region",
    "ServiceName",
    "ZoneName",
    "Category",
    "Menu",
    "ResourceDisplayName",
    "StartDate",
    "EndDate",
    "Usage",
    "Allocated",
    "Running",
    "Stopped",
    "Amount",
    "Tax",
    "Net"
  ];
  if (!sheet) {
    sheet = ss.insertSheet(this_month, 0);
  }
  if (sheet.getLastRow() == 0) {
    sheet.appendRow(["Date"].concat(keys));
  }
  data.forEach(function(resource) {
    var values = [today].concat(keys.map(function(key) { return resource[key]; }));
    sheet.appendRow(values);
  });
}

// Slackに現在の請求額を投稿する
function postTotalAmountToSlack(webhook_url, data) {
  var total_amount = 0;
  data.forEach(function(resource) {
    total_amount += resource["Amount"];
  });
  var message = "今月分の請求額は現在" + total_amount + "円です";
  var params = {
    "method": "post",
    "payload": 'payload=' + JSON.stringify({"text": message})
  };
  UrlFetchApp.fetch(SLACK_WEBHOOK_URL, params)
}

function main() {
  var this_month = getThisMonth();
  var ss = SpreadsheetApp.openById(SPREADSHEET_ID);
  var sheet = ss.getSheetByName(this_month);
  
  var data = getUsageData(this_month);
  sendUsageDataToSpreadsheet(ss, sheet, data);
  postTotalAmountToSlack(SLACK_WEBHOOK_URL, data);
}

貼り付けると下図のようになります。(キー、IDはご自分の環境の値に書き換えて下さい。)

f:id:asasaki:20160824140432p:plain

適当な名前をつけて保存し、メニューから「実行 > main」を選択して実行します。スプレッドシートの操作と外部サービスへの接続の許可がもとめられたら許可してください。完了するとスプレッドシートの新しいシートに利用明細の内容が入力され、Slackに請求額が通知されます。

最後にトリガーを設定し1日1回実行されるようにします。メニューから「リソース > 現在のプロジェクトのトリガー」からトリガーを追加し、下図のように「日タイマー」で適当な時間に実行するようにしておけばOKです。

f:id:asasaki:20160824140629p:plain

これで自動で毎日今月分の利用明細がスプレッドシートに追記、請求額がSlackで通知されるようになりました!

f:id:asasaki:20160824143936p:plain

利用明細がたまってきたらピボットテーブルなどで集計しグラフを描いてみると、日々の利用状況の変化が一目瞭然となります。 例えば、下図では8/10〜8/18まで仮想マシンは停止中で課金されていないのですが、ボリュームが毎日33-35円程度課金されていることがわかります。8/19以降は仮想マシンも毎日30円程度課金されていることから新しく仮想マシンを作成したか既存の仮想マシンを起動したこともわかります。

f:id:asasaki:20160823155155p:plain

請求額に占める割合が大きいボリュームについてもう少し詳しく見てみましょう。Menu列とUsage列を使うとRoot Disk、Data Diskごとの使用量を見れます。8/10〜8/17まで1日で使用量がData Diskの値が480GB-Hour、Root Diskの値が360GB-Hour増えていることから、24時間で割るとData DiskとRoot Diskがそれぞれ20GB、15GB存在していたことがわかります。その後、Data Diskが不要であったことから削除するとその後は値が増えなくなり課金も止まっています。このように値の変化から無駄を発見し対応していくことで、より効率的にクラウドを使うことができます。

f:id:asasaki:20160823162550p:plain

利用明細をみるときの注意点

最後に利用明細やビリングAPIの結果をみるときに注意点について少し触れておきましょう。

利用明細やビリングAPIはあくまでも課金情報を提供するためのものなので、課金対象外のリソースの使用量が含まれていなかったり、計算方法がサービスにより異なることがあります。

例えば、IDCFサービス間のトラフィックについては課金対象外となるため合計使用量(Usage)には含まれていません。また、多くのリソースでは毎時の使用量を合計した合計使用量を課金に利用していますが、平均使用量を課金に用いるオブジェクトストレージのストレージの料金のような例外もあります。このようなリソースでは合計使用量(Usage)の値も課金に使用される値(オブジェクトストレージの例では平均使用量)になるので注意が必要です。各リソースで使われている単位や請求額の計算方法については各サービスのドキュメントを参照してください。

おわりに

IDCFクラウドの料状況を利用明細とビリングAPIを使って把握する方法をご紹介しました。 コストの削減やリソース管理の効率化にお役にたてば幸いです。

超高速NoSQLデータベースAerospikeを試してみた

IDCFクラウド ビッグデータ

お久しぶりです、ソリューションアーキテクト部の金杉です!

今年度から、ソリューションアーキテクト部に新たにエバンジェリストグループができました。いろいろと情報を発信していく他、みなさまのお役に立てるコミュニティテンプレートの公開も順次していこうと思います。本日は、その第一弾、Aerospike Server Community Editionテンプレートの使い所を紹介しますー!

Aerospikeってなに?

社会がビッグデータやIoT革命を起こしている今、アプリケーションはより高品質なデータベースを必要としています。"高品質"には、リアルタイムで的確に答えを出せる速度と、より膨大なデータを処理できるスケーラビリティが求められています。Aerospikeは、そのようなニーズを満たす、速度とスケーラビリティを両立させた高性能なNoSQLデータベースサーバーです。

www.aerospike.jp

今回のブログでは、簡単に以下4点を紹介します!

  1. Aerospikeのすごいところ
  2. IDCFクラウドでAerospike Serverを立ててみる(500円でできるんだぜ)
  3. AMCから確認してみる
  4. C言語のクライアントとベンチマークツールを試してみる
続きを読む

第一回MORIO Dojo入門者限定イベント ~Dojo開き~

MORIO Dojo(アンバサダー)

こんにちは。MORIO Dojo女将の谷口(ワタシ)です。

MORIO Dojoとは2016年5月10日から始まった、IDCFクラウドのアンバサダープログラムです。

応募して、認定されると限定イベントへの招待や限定クーポンなどの参加者特典を受けることができます。

早速ですが、先日(7月21日)に第一回MORIO Dojo入門者限定イベント(@Debarge)を開催しました!

雨も止んで、たくさんのDojo入門者のかたにお会いできましたので、そのご報告です!

当日のプログラムは以下の通り。


  • 開会のご挨拶/乾杯
  • MORIO Dojo認定証授与式
  • LTタイム
  • IDCFクラウドマニアッククイズ!
  • みんなのブログを知ろう!
  • 閉会の儀

開会のご挨拶/入門の御礼は、女将から。入門者のかたと、杯を交わすことができました!w f:id:santaniguchi:20160722162841p:plain

MORIO Dojo認定証授与式

MORIO Dojoに入門いただいた皆様に認定証をお渡ししました! f:id:santaniguchi:20160722171000j:plain

こちらのカード、入門者の方々のDojoネーム(ハンドルネーム的なもの)を1枚1枚印字しました。 皆様で同じDojoグッズを持つことで、一体感を持っていただけるかな?という想いで作りました。(オネガイダカラ..ポイ.シナイデ...)

認定証授与の様子です。喜んでいただけてよかったですー(MORI帯、黒帯認定おめでとうございます!) f:id:santaniguchi:20160722170752p:plain

LTタイム

f:id:santaniguchi:20160722183337j:plain

①IDCFクラウド開発最新情報

IDCFクラウドの開発チーム(飯田)からIDCFクラウドの今年度の新機能リリース実績と、これからの開発ロードマップのお話をさせていただきました。 ILB(7/14)、GSLB(7/21)リリースの話と、現在開発中の機能・サービスのロードマップについての「ここだけの話」なので詳細はヒミツです。気になる方ははMORIO Dojoへの入門をお待ちしてます! www.idcf.jp

②エバンジェリストグループの藤城から「僕はまだ10%しかIDCFクラウドを理解していなかった」

(半分は本の宣伝?!笑)

www.slideshare.net

③最後に入門者の(@hogehuga)さんから「(Vulsで)脆弱性対策をもっと楽に!」

ユーザー会に続き、Vulsネタ!

www.slideshare.net

IDCFクラウドマニアッククイズ

IDCFクラウドに関するアンバサダーだから、応えられるようなマニアックなクイズをご用意し、優勝者には未発売の「IDCFクラウド攻略」ガイドをプレゼントしました! 後半はかなりの難問が多く、アンバサダーの方々も自信なさげwというか、社内のメンバーですら答えられるか怪しいレベルの問題でした! ぜひ挑戦してみてください!

www.slideshare.net

みんなのブログを知ろう!

他の入門者は何を書いてるのかな?失敗や成功を共有してほしい!という想いから「みんなのブログ」と題して、Dojo入門者のみんなが書いているブログを紹介させていただきましたー!WP系、IDCFクラウド使い倒す系、IoT(IDCFチャンネル)系など人によって、分野が分かれており、個人的にとっても面白かったです! 帰り際に「もっとブログ書きます!」という声もいただき、ブログ紹介は定期的に実施していきたいと思います♪

閉会の儀

とまぁ、このようなかんじで緩やかに進行していったDojo開きですが、入門者のみんなの笑顔で終了することができました! f:id:santaniguchi:20160724174837j:plain

IDCFクラウド MORIO Dojoでは入門者を絶賛募集しています!また、MORIO Dojoのプログラムもブラッシュアップしていきたいので、入門者からの要望もお待ちしております!

ではでは、次回は自分もイベントに参加したいよ!という方は、↓こちらからご応募お待ちしております~

www.idcf.jp

YBIのクエリ結果をSlackへ通知する

Yahoo!ビッグデータインサイト ビッグデータ

ビッグデータ・ソリューションアーキテクトの高階(takashina)です。

みなさんの社内や組織内のコミュニケーションには、どんなツールを使ってますか? 電話、メール、ケータイメッセージはもちろんのこと、LINE、FacebookのMessenger、Skype、Facetime、Slack、chatwork、HipChatなどといった様々なジャンルのツールを使っているかと思います。プッシュ通知されるツールだと、タイムラインを追っていくだけで必要な情報や通知内容が読めるので、手間が少なくて便利ですよね。

ログのバッチ処理をしている場合、自動的にその集計結果を送ってきてもらえたら、それも手間が少なくて便利そう。 そこで今日は、Yahoo!ビッグデータインサイト(以下「YBI」)で実行したクエリの結果をSlackへ通知する手順についてご紹介します。
f:id:maktakas:20160530124256p:plain

前提条件

ここから先、次の前提で綴っていきます。

  • CentOSサーバーの基本的な操作ができる
  • 外部のBotから投稿してもOKなSlackのアカウントを持っている
  • YBIのアカウントを持ち、YBIの基本機能を理解している

用意するモノ

手順

1. IDCFクラウドで仮想サーバー作成、ネットワークの設定

まずはIDCFクラウドでSlackへの投稿を操作するサーバーを作ります。 他のサーバーを使う方は、適宜同様の設定をしてください。

IDCFクラウドで仮想サーバーを作成する手順についてはIDCFクラウド ヘルプサイトをご覧ください。 なお、今回はおすすめTemplateのCentOS 7.1 64-bitで作成しました。
ネットワークの設定は下記のように行います。 SSH(22/TCP)とSinatra(4567/TCP)でアクセス可能としてください。
※Sinatraが何者か、は後述します。

まずIPアドレスの取得
f:id:maktakas:20160523204354p:plain

ファイアウォールの設定
f:id:maktakas:20160523204433p:plain

ポートフォワードの設定
f:id:maktakas:20160523204503p:plain

2. Slackでの準備

続いてSlack側で準備をしていきます。通知を送りたいSlackのteamにアクセスしておきましょう。

外部のツール等からSlackへ投稿できる機能としてIncoming Webhooksがあります。今回はこの機能を使ってYBIからSlackへのクエリ結果通知を実現していきます。
なお、既にIncoming Webhooksの設定がされているSlackのChannelであれば、ここの手順は不要です。

2-1. Slack設定ページ

歯車マークのChannel Settingsから「Add an app or integration」を選択します。
f:id:maktakas:20160520143305p:plain

すると、Slackの細かな設定ができるページへ飛びます。 ここの検索窓で「incoming webhooks」を入力すると候補に「Incoming Webhooks」が現れるのでクリックします。

2-2. Incoming Webhooks設定ページ

f:id:maktakas:20160520143621p:plain

team名の右側にある「configure」、「Add Configuration」とクリックします。
f:id:maktakas:20160520144728p:plain f:id:maktakas:20160520144733p:plain

Post to Channelで、Incoming Webhooksで投稿する先のchannelを選択して、 「Add Incoming WebHookss integration」ボタンをクリックします。
f:id:maktakas:20160520145011p:plain

2-3. 投稿用URLの発行

https://hooks.slack.comで始まるWebhook URLが発行されます。 外部ツールからこのURLにデータを投げるとSlackのChannel投稿されるわけです。
f:id:maktakas:20160520145956p:plain

このページでは、Webhookを使った投稿者名、アイコン等を変更することができますが、とりあえず今はそのまま次に進みます。 「Save Settings」をクリックして、Slack側での準備は完了です。

※注意!
このWebhook URLは関係者以外に知られないようにしてください。バレてしまうと誰でもChannelへ投稿できるようになってしまいます!

2-4. Webhook URLのテスト

Webhook URLを使った投稿ができるかどうか、CentOSサーバーにログインして、試してみましょう。

$ curl -X POST --data-urlencode 'payload={"text": "Test Message"}' https://hooks.slack.com/services/xxxxxxxxx/xxxxxxxxx/xxxxxxxxxxxxxxxxxxxxxxxx

うまく行けば、SlackのChannelにこんな投稿がされているはずです。
f:id:maktakas:20160523155616p:plain

3. td2slackの準備

続いて、CentOSサーバーにてtd2slackをインストールします。 YBIはTreasure Dataのサービスをベースにしています。YBIからSlackへ通知する仕組みについては、Treasure Dataのクエリ結果をSlackに流せる「td2slack」があるので、これを使います。

td2slackは、RubyによるWebアプリケーションを簡単に実現するためのソフトウェアであるSinatraで作られています。 今回ご紹介しているtd2slackは、YBIから送られてきたHTTP PUTをSinatraでフッキングしてSlackへ送る、という動きをしています。
Sinatraについて詳しく知りたい方はこちらをどうぞ

3-1. yumインストール

td2slackをインストールするのにbundlerを使っていきます。
その前に、インストールに使うruby-devel、gcc、rubygem-bundlerをyumでインストールします。RubyGemsもアップデートしておきましょう。

$ sudo yum install ruby-devel gcc rubygem-bundler
(中略)
New leaves:
  gcc.x86_64
  ruby-devel.x86_64
  rubygem-bundler.noarch

$ sudo gem update --system
Updating rubygems-update
Fetching: rubygems-update-2.6.4.gem (100%)
Successfully installed rubygems-update-2.6.4
Installing RubyGems 2.6.4
RubyGems 2.6.4 installed
(中略)
RubyGems system software updated

3-2. git clone

適当なディレクトリ配下にgit cloneします。

$ git clone https://github.com/treasure-data/td2slack.git
Cloning into 'td2slack'...
remote: Counting objects: 49, done.
remote: Total 49 (delta 0), reused 0 (delta 0), pack-reused 49
Unpacking objects: 100% (49/49), done.

3-3. 環境変数設定

下記の環境変数を設定します。

$ export SLACK_WEBHOOK_URL=https://hooks.slack.com/services/xxxxxxxxx/xxxxxxxxx/xxxxxxxxxxxxxxxxxxxxxxxx
$ export RACK_ENV=production
  • Sinatraアプリケーション(app.rb)からSLACKへ投稿する際に、SLACK_WEBHOOK_URLの環境変数で指定したURLへ送っています。
  • RACK_ENVは、Sinatraアプリケーションを外部のサーバーから利用できるようにするために設定しています。

3-4. td2slackインストール

td2slackで使われるjsonのgemがGemfileに含まれていなかったため、追記したうえでbundlerでインストールします。

$ cd td2slack
$ vi Gemfile
source 'https://rubygems.org'
gem 'sinatra'
gem 'slack-notifier'
gem 'json'     (← 一行追加)

$ bundle install --path vendor/bundle
Fetching gem metadata from https://rubygems.org/.............
Resolving dependencies...
Installing json 1.8.3
Installing rack 1.6.0
Installing rack-protection 1.5.3
Installing tilt 2.0.1
Installing sinatra 1.4.6
Installing slack-notifier 1.1.0
Using bundler 1.7.8
Your bundle is complete!
It was installed into ./vendor/bundle

これで実行環境が整いました。

4. 実行テスト

とりあえず実行してみましょう。

$ bundle exec ruby app.rb
[2016-05-23 20:21:05] INFO  WEBrick 1.3.1
[2016-05-23 20:21:05] INFO  ruby 2.0.0 (2014-11-13) [x86_64-linux]
== Sinatra (v1.4.7) has taken the stage on 4567 for production with backup from WEBrick
[2016-05-23 20:21:05] INFO  WEBrick::HTTPServer#start: pid=11116 port=4567

この状態でYBIのWeb UIからクエリを実行してみます。 適当なDatabaseを選んで、テスト用に「SELECT 'aaa' AS foo」などという単純なクエリを書きます。 このクエリの結果は「foo」カラムに「aaa」という文字列が1行だけ現れます。
f:id:maktakas:20160523211531p:plain

これをResult Exportの機能で「HTTP PUT」へエクスポートします。記入個所はHost、Port、Pathの3箇所です。
f:id:maktakas:20160523211541p:plain

ここまで設定したら、Web UI右上にある「Run」!

すると..Slackにこんな投稿がされるはずです。
f:id:maktakas:20160523212329p:plain

CentOSサーバーにはこんなログが出てます。

WARN: tilt autoloading 'tilt/erb' in a non thread-safe way; explicit require 'tilt/erb' suggested.
xxx.xxx.xx.xx - - [23/May/2016:20:23:54 +0900] "PUT /example HTTP/1.1" 200 - 0.4638
xxx-xxx-xx-xx.jp-east.compute.idcfcloud.com - - [23/May/2016:20:23:54 JST] "PUT /example HTTP/1.1" 200 164
- -> /example
[2016-05-23 20:23:54] ERROR Errno::ECONNRESET: Connection reset by peer
        /usr/share/ruby/webrick/httpserver.rb:80:in `eof?'
        /usr/share/ruby/webrick/httpserver.rb:80:in `run'
        /usr/share/ruby/webrick/server.rb:295:in `block in start_thread'

確認できたらSinatraは止めておきましょう。Ctrl-Cです。

5. td2slackをデーモンで動かす

Sinatraアプリであるtd2slackは、rackupコマンドでデーモン起動可能です。下記では4567/TCPポートで起動しています。netstatで起動状況を確認してみましょう。

$ bundle exec rackup -D config.ru -p 4567

$ netstat -tnap
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:4567            0.0.0.0:*               LISTEN      18591/ruby      

止める時はkillしてください。

$ kill -9 ${pid}

6. 出力結果のフォーマット作成

Result Exportを設定する際に、 Path: /example と設定しました。 これは、CentOSサーバーのtd2slack/viewsディレクトリ配下にあるerbファイルに沿って出力されています。 example.erbファイルを見てみると..

$ more views/example.erb
This is <%=@td['foo'][0]%>

クエリの結果は「foo」カラムに「aaa」という文字列が1行だけ現れるもので、Slackへの投稿された内容は以下の通りでした。
f:id:maktakas:20160523212329p:plain

<%=@td['foo'][0]%>の部分にクエリ結果の「aaa」が代入されていたのですね。 このようにviewsディレクトリ配下のerbファイルを設定すると、いろいろと出力結果をカスタマイズできます。

ところで、YBIにはsample_datasetsというデータベース内に、過去のNasdaq株価データが入ったテーブルがサンプルデータとして格納されています。このデータセットに対して、次のようなクエリを実行して、結果をSlackへ流してみましょう。Sinatraアプリを起動しておくのをお忘れなく。

$ bundle exec rackup -D config.ru -p 4567

設定ファイル:トップ5をフォーマットして表示しています。

$ vi views/rate_of_increase.erb
Nasdaq株価上昇率トップ5
日付 | 銘柄 | 上昇率
<% 5.times do |i| %>
  <%= i + 1 %>位 <%= @td['date'][i] %> | <%= @td['symbol'][i] %> | <%= @td['rate_of_increase'][i] %>
<% end %>

クエリ:日毎・銘柄毎の株価上昇率を計算して、上昇率トップ5を取得しています。

SELECT TD_TIME_FORMAT(time, 'yyyy-MM-dd') AS date, symbol, (close - open) / open AS rate_of_increase
FROM nasdaq
WHERE TD_TIME_RANGE(time, '2012-01-01', '2013-01-01')
  AND (close - open) > 0
  AND open > 0
ORDER BY rate_of_increase DESC
LIMIT 5

Result Exportの設定は次のようにします。

Export to: HTTP PUT
Host: td2slackが動くホスト名かIPアドレス
Port: 4567
Username: 空白
Passowrd: 空白
Path: /rate_of_increase

クエリをRunしてみましょう。Slackへ出力される結果は次のようになるはずです。
f:id:maktakas:20160524212506p:plain

今回の環境

$ cat /etc/redhat-release
CentOS Linux release 7.2.1511 (Core)
$ /usr/bin/ruby -v
ruby 2.0.0p598 (2014-11-13) [x86_64-linux]
$ /usr/bin/gem -v
2.6.4
$ /usr/bin/bundler -v
Bundler version 1.7.8

おわりに

いかがでしたか。
クエリ結果を定期的にSlackへ出力してもらえると、監視アラートの代わりに使うこともできますね。

それでは、ごきげんよう!

ボリュームアップロード機能の紹介

IDCFクラウド API

こんにちは。IDCフロンティア UX開発部の進藤です。

5/19にIDCFクラウドにおきまして、ボリュームアップロード機能をリリース致しました。
IDCFクラウド以外の環境(他社クラウドサービス等)で作成されたボリュームを、より簡単にIDCFクラウドでご利用頂けるようになりました。
ボリュームアップロード機能は、クラウドコンソール画面からはもちろん、APIもご利用頂けます。

この記事では、ボリュームアップロード機能の具体的なご利用方法を紹介します。

準備

ご準備頂くのは、OVA形式のボリューム だけです!

APIから実施される場合は、CloudStackのAPIを実行できる環境もご用意ください。

以降では例として、IDCFクラウドで作成したボリュームを、別アカウントのIDCFクラウドにアップロードする方法をご紹介します。

なお 例で使用するアカウントは下記の通りとします。
 - アップロード アカウント:アカウントA
 - アップロード アカウント:アカウントB

アカウントAのボリューム(OVAファイル) f:id:cshintoidcf:20160524174143p:plain

今回はこちらのURLのボリュームを使用します。


IDCFクラウドコンソールでアップロードする

まずは、IDCFクラウドのコンソールにてアップロードする方法を紹介します。

1. アップロード先のアカウントでログインします。

例では、アップロード先のアカウントを"アカウントB"としています。 f:id:cshintoidcf:20160524172609p:plain

2. 「コンピューティング」>「ボリューム」へ遷移し、「ボリューム作成」をクリックします。

f:id:cshintoidcf:20160524171614p:plain

3. 「アップロード」をクリックし、必要事項を入力します。

《入力事項》

  • ボリューム名:任意の名前をご入力ください
  • ゾーン :アップロードするゾーンをご選択ください
  • URL :OVAファイルのURLをご入力ください
  • ※"http://*****.ova"形式のファイルのみアップロード可能です。
    お持ちのOVAファイルのURLが"https://・・・.ova"の場合、"s"を削除してご入力ください。

    f:id:cshintoidcf:20160524171902p:plain
    入力が完了したら「作成する」をクリックします。
    確認画面が表示されたら、「はい」をクリックしてください。

    4. アップロードが完了するまで待ちます。

    f:id:cshintoidcf:20160524171936p:plain

    アップロードが完了すると、ステータスが「Uploaded」に変わります。
    図はアップロードしたボリュームの詳細画面です。
    アカウントBにOVAファイルがアップロードできました。 f:id:cshintoidcf:20160524172654p:plain

    仮想マシンにアタッチしてみる

    アップロードしたボリュームはそのまま仮想マシンへアタッチできます。

    1. アカウントBでアップロードしたボリュームの詳細画面で、「アタッチ」をクリックします。

    f:id:cshintoidcf:20160524172716p:plain

    2. アタッチ先の仮想マシンを選択して、「アタッチする」をクリックします。

    f:id:cshintoidcf:20160524172741p:plain

    アタッチが完了すると、アタッチ先仮想マシン名が表示され、ステータスもReadyに変わります。 f:id:cshintoidcf:20160524172759p:plain アタッチ完了後ボリューム詳細画面
    これでアカウントBの仮想マシンでボリュームが使えるようになりました。
    f:id:cshintoidcf:20160524172815p:plain

    CloudStack APIを実行してアップロードする

    次にCloudStackのAPI:uploadVolumeでのアップロード方法を紹介します。

    1. 利用可能なゾーンを確認する

    listZones やlistVolumesを実行し、IDCFクラウドのアップロード先のアカウントBで有効化されているゾーンを確認します。
    今回はuploadVolume実行後との比較のためlistVolumesを実行しました。
    エンドポイントは西日本リージョンを指定しています。

    $ cs listVolumes
    {
      "count": 2,     //作成済ボリュームは2台ある
      "volume": [
        {
          "account": "*************", 
          "attached": "2016-05-24T15:39:48+0900", 
          "created": "2016-05-24T15:35:31+0900", 
          (中略)
          "name": "UpLoad_Test001",     //先程IDCFクラウドコンソールからアップロードしたUpLoad_Test001
          "pcidevicepath": "*************", 
          "provisioningtype": "thin", 
          "quiescevm": false, 
          "size": 16106127360, 
          "state": "Ready", 
          "storagetype": "shared", 
          "tags": [], 
          "type": "DATADISK", 
          "virtualmachineid": "*************", 
          "vmdisplayname": "testS1-w", 
          "vmname": "testS1-w", 
          "vmstate": "Running", 
          "zoneid": "{augusta_zoneid}",     //augustaゾーンのID(ボリュームアップロード時に使用します)
          "zonename": "augusta"
        }, 
        {
          "account": "*************", 
          "chaininfo": "{\"diskDeviceBusName\":\"scsi0:0\",\"diskChain\":[\"[jw01v-str03-p01b-DS23] i-1953-20809-W1VM/ROOT-20809.vmdk\"]}", 
          "created": "2016-05-17T14:30:33+0900", 
          (中略)
          "name": "ROOT-20809", 
          "provisioningtype": "thin", 
          "quiescevm": false, 
          "serviceofferingdisplaytext": "1 CPU x 0.8 GHz / 1 GB RAM", 
          "serviceofferingid": "*************", 
          "serviceofferingname": "light.S1", 
          "size": 16106127360, 
          "state": "Ready", 
          "storagetype": "shared", 
          "tags": [], 
          "templatedisplaytext": "Root Disk: 15GB,(v2)", 
          "templateid": "*************", 
          "templatename": "CentOS 7.1 64-bit", 
          "type": "ROOT", 
          "virtualmachineid": "*************", 
          "vmdisplayname": "testS1-w", 
          "vmname": "testS1-w", 
          "vmstate": "Running", 
          "zoneid": "{augusta_zoneid}", 
          "zonename": "augusta"
        }
      ]
    }


    2. uploadVolumeを実行する

    必要なパラメータを指定してuploadVolumeを実行します。

    • パラメータ
      • zoneid:アップロード先ゾーンのid(listZones等で取得)
      • format:OVAを指定
      • name:任意のボリューム名(例ではUplLoad_Test002)
      • url:ボリュームのURL
        ※uploadVolumeでは、"http://・・・.ova" 形式のファイルのみご利用頂けます。
        例では準備にて記載している アカウントAで作成したボリュームを指定しています。


    uploadVolume実行例

    $ cs uploadVolume zoneid={augusta_zoneid} format=OVA name=UpLoad_Test002 url=http://X-X-X-X.systemip.idcfcloud.com/userdata/2e94a824-89fb-43cc-b177-31583d57a774.ova
    Polling result... ^C to abort
    {
      "accountid": "*************", 
      "cmd": "org.apache.cloudstack.api.command.user.volume.UploadVolumeCmd", 
      "created": "2016-05-24T15:45:40+0900", 
      "jobid": "*************", 
      "jobprocstatus": 0, 
      "jobresult": {
        "volume": {
          "account": "*************", 
          "created": "2016-05-24T15:45:40+0900", 
          "destroyed": false, 
          "diskofferingdisplaytext": "Custom Disk", 
          "diskofferingid": "*************", 
          "diskofferingname": "Custom", 
          "domain": "*************", 
          "domainid": "*************", 
          "id": "*************", 
          "isextractable": true, 
          "name": "UpLoad_Test002", 
          "provisioningtype": "thin", 
          "quiescevm": false, 
          "size": 0, 
          "state": "UploadNotStarted", 
          "status": "", 
          "storagetype": "shared", 
          "tags": [], 
          "type": "DATADISK", 
          "zoneid": "{augusta_zoneid}", 
          "zonename": "augusta"
        }
      }, 
      "jobresultcode": 0, 
      "jobresulttype": "object", 
      "jobstatus": 1, 
      "userid": "*************"
    }


    ステータスが"UploadNotStarted"となっていますが、listVolumesを実行すると、アカウントBの指定のゾーンに正常にアップロードされていることが確認できます。

    $cs listVolumes
    {
      "count": 3,     //1台アップロードしたため、作成済ボリューム台数が3になった
      "volume": [
        {
          "account": "*************", 
          "created": "2016-05-24T15:45:40+0900", 
          (中略) 
          "name": "UpLoad_Test002",     //APIからアップロードしたボリューム
          "provisioningtype": "thin", 
          "quiescevm": false, 
          "size": 16106127360, 
          "state": "Uploaded",          //ステータスがUploadedになっている
          "storagetype": "shared", 
          "tags": [], 
          "type": "DATADISK", 
          "zoneid": "{augusta_zoneid}", 
          "zonename": "augusta"
        }, 
        {
          "account": "*************", 
          "attached": "2016-05-24T15:39:48+0900", 
          "created": "2016-05-24T15:35:31+0900", 
          (中略) 
          "name": "UpLoad_Test001",     //IDCFクラウドコンソールからアップロードしたUpLoad_Test001
          "pcidevicepath": "*************", 
          "provisioningtype": "thin", 
          "quiescevm": false, 
          "size": 16106127360, 
          "state": "Ready", 
          "storagetype": "shared", 
          "tags": [], 
          "type": "DATADISK", 
          "virtualmachineid": "*************", 
          "vmdisplayname": "testS1-w", 
          "vmname": "testS1-w", 
          "vmstate": "Running", 
          "zoneid": "{augusta_zoneid}", 
          "zonename": "augusta"
        }, 
        {
          "account": "*************", 
          "chaininfo": "{\"diskDeviceBusName\":\"scsi0:0\",\"diskChain\":[\"[jw01v-str03-p01b-DS23] i-1953-20809-W1VM/ROOT-20809.vmdk\"]}", 
          "created": "2016-05-17T14:30:33+0900", 
          (中略)
          "name": "ROOT-20809", 
          "provisioningtype": "thin", 
          "quiescevm": false, 
          "serviceofferingdisplaytext": "1 CPU x 0.8 GHz / 1 GB RAM", 
          "serviceofferingid": "*************", 
          "serviceofferingname": "light.S1", 
          "size": 16106127360, 
          "state": "Ready", 
          "storagetype": "shared", 
          "tags": [], 
          "templatedisplaytext": "Root Disk: 15GB,(v2)", 
          "templateid": "*************", 
          "templatename": "CentOS 7.1 64-bit", 
          "type": "ROOT", 
          "virtualmachineid": "*************", 
          "vmdisplayname": "testS1-w", 
          "vmname": "testS1-w", 
          "vmstate": "Running", 
          "zoneid": "{augusta_zoneid}", 
          "zonename": "augusta"
        }
      ]
    }

    IDCFクラウドコンソールでも確認できます。 f:id:cshintoidcf:20160524172852p:plain

    (補足)CloudStack API実行環境について

    CloudStackAPI実行環境の構築方法はいくつかありますが、今回は以下の記事(Qiita)を参考にcsライブラリを使用しました。
    シンプルなCloudStack CLI/ライブラリ cs
    こちらも当社エンジニアが執筆しております♪

    詳細はQiitaの記事をご覧いただければと思いますが、環境構築方法を簡単にまとめますと次の様になります。

    • 使用環境
      • Mac OSX Yosemite10.10.5
    ①csライブラリインストール
    $which pip          //pipがインストールされているか確認
    $easy_install pip   //pipインストール
    $pip install cs     //csライブラリインストール

    ※pipはPythonを使用しているため 事前にPythonがインストールされているかご確認ください。


    ②.cloudstack.iniファイルの作成

    .cloudstack.iniファイルを新規に作成します。 .cloudstack.iniファイルに、次の様にIDCFクラウドアカウントのエンドポイント、APIキー、シークレットキーを記述して保存します。
    エンドポイント等は、IDCFクラウドコンソールの「コンピューティング」または「アカウント設定」> 「API」で確認することができます。

    $ vi .cloudstack.ini
    [cloudstack]
    endpoint = END_POINT //IDCFクラウドAPIエンドポイント
    key = API_KEY         //IDCFクラウドアカウントのAPIキー
    secret = SECRET_KEY   //IDCFクラウドアカウントのシークレットキー


    ③動作確認

    APIを正常に実行できるかどうか listZonesを実行して確認してみます。
    以下は、.cloudstack.iniでエンドポイントを西日本リージョンに指定した場合の実行例です。
    正常に完了すると augustaゾーンの情報が取得できます。

    $cs listZones
    {
      "count": 1, 
      "zone": [
        {
          "allocationstate": "Enabled", 
          "dhcpprovider": "VirtualRouter", 
          "id": "{augusta_zoneid}", 
          "localstorageenabled": true, 
          "name": "augusta", 
          "networktype": "Advanced", 
          "securitygroupsenabled": false, 
          "tags": [], 
          "zonetoken": "********"
        }
      ]
    }


    もし、下記の様なエラーがでたら、エラー内容に記載されている場所に.cloudstack.iniを移動させて再度実行してみてください。

    $ cs listZones
    Config file not found. Tried /{Path to .cloudstack.ini}/.cloudstack.ini, /{Path to cloudstack.ini}/cloudstack.ini


    おわりに

    IDCFクラウドコンソール、CloudStack APIを用いた外部でボリュームアップロード方法をご紹介しました。
    IDCFクラウドへの移行等の際に是非ご活用ください。

    ユーザーによるIDCFクラウド使いこなしブログご紹介! 〜ワンコイン(500円)クラウド編〜

    クラウド ワンコイン ブログまとめ

    こんにちは&はじめまして!オンライン開発部インサイドセールス担当の諌山です。 オンライン経由でIDCFクラウドをご利用いただいているお客様へのご提案・ご案内を担当しています♪ 何かお困りごとがありましたら、お気軽にインサイドセールスグループ宛にお問合せください!   

    さて、先日2/1(月)と2/16(火)に日本経済新聞本誌で「時代は、ワンコインクラウド。」としてIDCFクラウドの全面広告を出稿したのですが、みなさんご覧いただけましたでしょうか?!   

    f:id:hisayama0904:20160222104254p:plain     

    こんなに "ワンコイン推し!" なのはいいのだけれど、実際に「ワンコイン=500円」でどこまで使い倒せるのか?! ユーザー様にブログで自慢していただきましたので、厳選した記事をいくつかご紹介させていただきます🎶ヽ(*´∀`)ノ    

        

    「ワンコイン=500円」クラウド使いこなしブログ まとめ

    「1周年」 -KEi’s Log

    f:id:hisayama0904:20160222135848p:plain

     http://31kish.meltaba.com/2015-11-10/

    こちらのユーザー様は1台でWebサーバー&メールサーバーを動かしてるようです。 Minecraft用のサーバーとしてご利用いただいているお客様も多く、ワンコインでも「パワフル」に使いこなしていただけているようです!   

    IDCFクラウドのCentOS7でSwapを使う -いなばメモ

    f:id:hisayama0904:20160224100313p:plain

     http://blog.1783.org/2015/05/idcfcloud-swap/

    先ほどの記事でもCPUの性能についてご意見いただいていますが、ワンコインクラウドのCPU(1コア)よりも性能が欲しい方はSwap領域を作成し駆使しているようです。CentOS7での作成方法を紹介いただいています。

    ※IDCFクラウドの標準機能ではSwap領域の提供はありません。   

    「IDCFクラウドで自分だけのHerokuを構築する」 -もくもくブログ

    f:id:hisayama0904:20160222140436p:plain

     http://blog.muuny-blue.info/c3daba8ba04565423e12eb8cb6237b46.html

    この方はDokkuをIDCFクラウドで構築し、Herokuからいくつかのアプリを乗せ替えて利用されているようです。

     IDCFクラウド借りました

    初めてご利用いただく方からよくご質問を受けるのが、仮想ルーターの設定で、FirewallとPort forwardingの概念。 このエントリーでは構成図をもとに、わかりやすく解説されていて、ありがたいです★またこちらでもSwap領域の作り方を伝授。(DokkuはDockerベースなのでSwap領域があったほうがよさそうとのこと。)

     IDCFクラウドの一番安いのでDokkuを使う

    DNSの設定も含めた構築手順の詳細を公開しています。さらにPythonのサンプルアプリで一緒にインストールしてみましょう!   

    法人での使いこなし術🎶

    個人ユーザー様の使いこなし術をご紹介しましたが、法人様でももちろん!使いこなしていただいています。

    まだAWSのみに頼って生きてるの?複数のクラウド利用で、大幅コストダウンした話 -Qiita: @appwatcher

    qiita.com

    この方は個人でご利用いただいていたあとに所属する法人様でもIDCFクラウドを採用いただいたようです。 他社のクラウドサービスを使ってサービスを立ち上げた後、ユーザー様が想定よりも増えてその分費用も増大に!(汗)嬉しい悲鳴ということでしょうか。。 そこで弊社サービスの特徴(ネットワーク費用の定額プラン)を活かした構成を組み直して1/10にコストを抑えたそうです。
    移設は3人/日程度というスピードで達成し、サーバー側はAnsibleのレシピを少し修正したくらいとか…!DBはデータアクセスをAPI化されたようですが、Goで実装していたため型の安全性が生きたようです。
    スピード移行のためには、やはり新規サービス立ちあげ時の設計がポイントのよう。「自分のサービス形態の特質に合わせて、ライブラリやサービスの境界を分離できるようにしておく」など、事前に検討しておくことをいくつかアドバイスされていますので、これから新規サービスで利用検討いただいている方はぜひご参考にしてみてください!

    マルチクラウドユーザーとしてのご意見や、一番苦労された部分も詳しく伺ってみたいです!
       

    まとめ

    いかがでしたか?? やはり個人ユーザーの方はゲームなどでのProxyサーバー、ご自身の開発環境にご利用いただいている場合が多いようですね。 まだまだ、IDCFクラウドを独自の方法で使いこなしているよ!という方もいらっしゃるかと思いますので、ぜひ教えてください! また次の機会にこちらでまとめさせていただきます!   


     ◆ 「ブログ書いたよ!」お問い合わせ先 ◆

      株式会社IDCフロンティア   オンライン開発部 インサイドセールスグループ   inquiry@idcf.jp


    ぜひぜひ、お待ちしておりますよーーー!!! では、またお会いしましょう〜!゚・:.。..。.:・゜(´∀`)。. .。.:・゜゚・*   

    ▼ ワンコインキャンペーン実施中! << 期間:2016年2月1日〜2016年3月16日まで >>

    www.idcf.jp

       

    関連記事

    Copyright © IDC Frontier Inc.