IDCF Tech-Blog

IDCF テックブログ

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

IDCFクラウドでのマルチキューネットワーク

f:id:tafujish:20170127205753p:plain

仮想環境や古いサーバーだと上記画像のように、CPU使用率が特定のコアに偏ることがあると思います。特に2番のCPUのsi(ソフトウェア割り込み)の値のみ大きいです。このような場合、マルチキューネットワークに対応することで複数のCPUコアを利用することができるためネットワーク性能をスケールすることができます。

この話はしばしば質問いただきますが、IDCFクラウドの仮想マシンのNICはRSS(Receive Side Scaling)に標準で対応しているので、マルチキューネットワークのためにこれといった操作や設定は不要です。

「以上です。」
で終わってしまいそうな話ですが、以下ではもう少し踏み込んでみるので、CPUの各コアの利用が偏っている場合は次を参照ください。だいたい多い話として、irqbalanceが入っていなかったり、ダイナミックスケール後の話だったり、ISOから作った仮想マシンだったりします。

続きを読む

コーポレートサイトのセキュリティ対策は万全ですか?

はじめましてみなさん、コンテンツマーケティング部の河田です。
おもにIDCフロンティアのコーポレートサイトの運営を担当しています。

f:id:dkawata:20161226185447p:plain

当社のことをみなさんに知っていただく看板サイトとして、日々、新サービスの紹介やイベント、キャンペーン情報などを発信し続けています。
本日は、IDCFクラウド上で稼働しているコーポレートサイトを運用し続けるための仕組みを次のポイントに分けてわかりやすくご紹介していきたいと思います。

はじめに

今回お伝えしたい内容がこちらです。

  • 24時間365日運営できるサイト作り
  • サイトを守るために必要な3つの対策
    • GSLBによる広域負荷分散
    • DDoS対策サービスの導入
    • WAFの活用
  • 実際に障害が起こってしまったら
  • 最後に

前提となるWeb上の脅威のお話から、具体的な対策方法、障害発生時への備えまで一連の流れでご紹介したいと思います。では早速、本題に入りましょう。

24時間365日運営できるサイト作り

Webの世界にはリアル社会のように年末年始の休業期間などはありません。 基本的に24時間365日、サイトを運用し続けることが前提となります。
そしてWeb上でサービスを提供しているかぎり尽きないのがサイバー攻撃の脅威です。
中でもコーポレートサイトのような会社のブランディングに直結するサービスには DDoS攻撃などが猛威を振るってきます。 TCP・SYNフラッド、UDPフラッド、DNSアンプ、Low and Slow攻撃など、その種類は上げればきりがないくらい存在します。
また、それぞれの攻撃が狙うターゲットレイヤーも異なり、その規模もどんどん大きくなってきています。

こうした悪意のある攻撃からサイトを守るためには、単純にサーバーを強化するだけでは対策不足です。ネットワークインフラからサーバーまで一貫した対策が必要になります。

サイトを守るために必要な3つの対策

IDCFのコーポレートサイトは、これからご説明する3つのサービスを用いてセキュリティ対策を実現しています。
では、実際にどのような取り組みをしているのか簡単にご紹介していきます。

1)GSLBによる広域負荷分散

サイバー攻撃に関わらず、人為的なミスや大規模災害などが起きて、サーバーに何らかの障害が発生した場合、ただちにGSLBは登録されているディザスタリカバリ(DR)サイトへ自動でアクセスを切り替え、ダウンタイムを 最小限に抑えてくれます。
通常のロードバランサーと違い、東西の拠点でロードバランシングを行うため、より一層可用性が担保されます。アクセス数の多い都心部からのレイテンシを考慮し、プライマリサイトを東日本に構築していることもポイントです。
そして、拠点間でのコンテンツ同期やバックアップを行い、さらにプライベートコネクト接続で セキュアな通信網を利用すればベストです。

f:id:dkawata:20170106140952p:plain
▲GSLBによるDRサイトへの自動切り替わりイメージ

2)DDoS対策サービスの導入

このDDoS対策サービスというのは、トラフィックがサーバーに届くより前の段階のネットワーク領域でDDoS攻撃を緩和、防御してくれます。

もう少し詳しく説明すると、以下のフローを自動で行います。
1. ネットワーク上の振る舞いから悪意のあるトラフィックを検知する
2. そのトラフィックを遮断するためのシグネチャを自動生成(動的シグネチャ
3. フィルタリングを実行

既知の攻撃手法に対しての防御は不正侵入検知/防御サービス(IDS/IPS)で対応可能ですが(静的シグネチャ)、未知の攻撃や巧妙に細工された攻撃にはこのDDoS対策サービスが特に効果を発揮します。

※静的シグネチャとは、既知の攻撃パターンをデータベース化して管理した上で、該当する攻撃をフィルタリングする方式です。

3)WAFの活用

WAFとはWeb Application Firewallの略称で、一般的によく知られているFirewallがポート、IP制限などのネットワークレイヤーの不正アクセスを防ぐのに対して、WAFは「SQLインジェクション」「XSS」などのWebアプリケーションを狙った攻撃を防御してくれます。

例えば、お問い合わせなどのフォームからサーバーへ送られる入力データのチェックを行い、不正なデータが渡されないようにします。つまりサーバーとクライアントの間に立って通信を遮断し、Webアプリケーションを防御してくれます。

しかしながら、WAFを導入すればすべてのWebアプリケーションの脆弱性対策ができるかというと、答えはNOです。 あくまで暗号化された通信(SSL)上でのセキュアなプログラミングや適切なサーバー設定の漏れを補完することが目的です。

f:id:dkawata:20161226185515p:plain
▲各レイヤーによりサイバー攻撃を防御する対象が異なる

こうしたネットワークサービスを導入することで、一定のサイバー攻撃からサイトを守ることができます。 しかもその負荷を専用機器でまかなうことができるため、Webサーバーに無駄な負荷をかけずに済みます。
SSLの暗号化・復号処理をサーバーではなく、ロードバランサーで行っていることもポイントの一つです(SSLアクセラレーション)。 普段何気なくアクセスしているコーポレートサイトも、コンテンツへ到達するまでには 上図のような様々なサービスを通過して閲覧できているワケですね。

実際に障害が起こってしまったら

ここからは人や組織の対策です。
あまり考えたくないことですが、実際に問題や障害が発生してしまった時の行動を緊急時対応マニュアルとしてフローチャート形式でまとめることや、エスカレーション先を決めた表を作成する必要があります。
この時、自分ひとりですべての作業を差配している人は少ないと思います。複数の部署をまたいだ連携が必要になってくるハズです。そのため、物事の決定権が誰にあるのかを事前に決めておくことは非常に重要です。できれば担当部署だけでなく、担当者名まで決めておくことができれば安心です。
またその代理や、最悪、誰とも連絡がつかなかった場合などその条件は多岐に渡りますが、まずは自分の上司など身近なところから決めて行き、表を完成させていきましょう。

まとめ

今回は少し駆け足でコーポレートサイトの全体像をお伝えしました。
以上のことを踏まえてIDCFのコーポレートサイトはざっくりと下図のような構成になっています。

f:id:dkawata:20161227171522p:plain

普段は個々のサービスとして独立して説明する機会が多いと思いますが、このように一連の流れで説明することで、それぞれのサービスが担当する守備範囲がわかりやすくなったのではないでしょうか。

要点をまとめてみます。

  • GSLBによるDRサイト構築
  • DDoS対策サービスを含むネットワークサービス(FW、IDS/IPS、WAF、LB)の導入
  • SSLによる通信の暗号化
  • セキュアなプログラミングや適切なサーバー設定
  • コンテンツの同期とバックアップ
  • 障害時の対応マニュアルの作成

これらがすべて揃って初めて24時間365日運営できるサイト作りが実現することになります。

最後に、今回取り上げたこれらのサービスを実際使ってみたいという方へのお知らせです。
中でもIDCFクラウド上で導入可能なGSLB(DNS)プライベートコネクトILBならすぐにでも対策を始めることができます。 また、お申込みベースでDDoS対策サービスを含むIDCFネットワークサービスも利用可能です。

これを機にみなさんが運営されているサイトのリスクマネジメント対策を見直してみてはいかがでしょうか?

超簡単〜ILBをMackerelで監視してみよう

こんにちは!ソリューションアーキテクト部の金杉です。

12/15(木)のアップデートで、IDCFクラウドILBのノードに対してMackerelを使った監視ができるようになりました。今まで、ILBに対しての監視サービスは提供されていなかったので、これでパフォーマンス調査やトラブルシューティングがだいぶ楽になりますね。

f:id:ykanasugi:20161220120547p:plain

ちなみにILBもMackerelも過去の記事で紹介してきましたが、ILBとはIDCFクラウド上で動作するオートスケール可能なロードバランサーで、Mackerelは株式会社はてなが提供するエージェント型のリソース監視ツールです。詳しくは、以下の記事を参考にしてください。

Mackerel関連記事
Mackerelブログリレー『第1回 新人がIDCFクラウドでMackerelを使ってみた』 Mackerelブログリレー『第2回 新人がMackerelにホスト登録してみた』

ILB関連記事
ILBを使ってWebサーバーをバランシング!構成事例もご紹介

はじめに

今回のアップデートのポイントを3つにまとめてみました。 ポイントの紹介後に、早速導入をしてみます。

1. Mackerelの導入が簡単かつ無料

ILBに対してのMackerel導入はとても簡単で、エージェントのインストールやコンフィグの書き換えなどの手間は一切不要です。設定の際にチェックを一つ入れて、APIキーを貼り付けるだけのめちゃ楽作業です。そして、無料です?

また、Mackerelインターフェイスでのメトリックグラフもすでに定義済みなので、手動で設定する必要もありません。現在は、以下3つの項目が見れるようになっています。項目ごとの説明はステップ③を参考にしてください。
1) Health Check Errors
2) Sessions
3) Traffics

2. UXを重視した見せ方

Mackerelを使って監視をする時、通常はサーバー1台ごとにリソースグラフが表示されますが、ILBでMackerelを使うとすべてのノードの状態をまとめて表示してくれます。

前提として、ILBは負荷に応じてオートスケールする(ノード数が増える)という特徴があります。しかし、ILBを監視する立場になると、ノード単体のリソース状況よりも全体のリソース状況が気になりますよね。よって、今回のアップデートではILBの全ノードを一体化したUX重視な見せ方を採用しています。

3. 稼働中のILBにも適用OK

「ええ!すごいじゃん!でもILBずっと昔に立てちゃったよ...」という方も、心配不要です!Mackerelの実装は、稼働中のILBに対しても可能です? 新規ILBとほぼ同様の方法で導入できるので、同じ手順を参考にしてください。

ILBにMackerelを導入してみる

それでは、早速ILBにMackerelをインストールしてみましょう。インストールには必ずMackerelのAPIキーが必要になってくるので、まずはMackerelの画面でAPIキーを確認し、その次にILBに対してインストールの手順を紹介します。

IDCFクラウドコンソールの上にカーソルを移動するとサービス一覧がでるので、そこからMackerelとILBの管理画面が開けます。 f:id:ykanasugi:20161219164644p:plain

①事前準備〜Mackerel API Keyを確認〜

まずはMackerelの管理画面に移動します。IDCFクラウドからはシングルサインオンができるので、便利です。新規登録ができていない方は、ぜひこれを機会に登録してみてください。無料で使える特典プランもあります。

左のメニューから対象のオーガニゼーションを選択します。続いて「APIキー」のタブをクリックします。ここでAPIキーのコピーができます。一番右のアイコンをクリックするとそのままコピーしてくれますのでぜひ活用ください。 f:id:ykanasugi:20161219164700p:plain

これでMackerelのAPIキーの確保ができましたので、ILBの設定に移ります。

②ILBにMackerelを導入

新規ILBに対してMackerelを導入する場合、まずILBの作成を行います。画面右上にある「ILB作成」をクリックします。 既存のILBの場合は、直接対象となるILBのILB名をクリックし、直接オプション入力のステップに移ります。

●パラメーター入力
ロードバランサーのネットワーク、FQDN、Configurationなどのパラメーターを入力します。設定で迷ったら、こちらの記事を参考にしてみてください。 f:id:ykanasugi:20161215210717p:plain

●オプション入力
一通り設定が終わったら、オプションの入力をします。Mackerelのインストールもここで選択します。
「リソース監視」の欄にチェックを入れたら、APIキーの入力欄が表示されるので、先ほど確認したMackerelのAPI Keyをペーストします。Firewallの設定も適宜入れます。終わったら、「確認画面へ」をクリックし、問題なければ作成をします。 f:id:ykanasugi:20161219164730p:plain

③MackerelでILBの様子を確認

ILBの画面にもどって、作成したILBのステータスがRunningになったらMackerelの画面で確認してみましょう。

Mackerelのダッシュボードで「Hosts」を確認すると、ILBのFQDNが表示されていて、ステータスがWorkingになっているはずです。 f:id:ykanasugi:20161219164754p:plain

上図のホスト名をクリックすると、各種メトリックグラフが見えます。例のILBでは、Webサーバー2台を分散させています。(10.15.0.98と10.15.0.245) f:id:ykanasugi:20161219113750p:plain   ▲Health Check Errorsのメトリック
ILBから分散先サーバーに対してのヘルスチェックの結果を見ることができます。値が1の時はヘルスチェック結果がエラーで、値が0の時はヘルスチェックが正常に通っているということになります。

f:id:ykanasugi:20161221103844p:plain   ▲Sessionsのメトリック
分散先サーバーごとのセッション数を見ることができます。さらにcurrentとrateで分かれており、currentは現在のセッション数で、rateは秒間の新規セッション数を表しています。
また、totalの値も見ることができます。currentのtotal値は分散先サーバーの合計のセッション数で、rateのtotal値は分散先サーバーの合計の新規セッション数です。

f:id:ykanasugi:20161221103849p:plain   ▲Trafficsのメトリック
分散先サーバーごとの秒間トラフィックを見ることができます。さらにtxBytesとrxBytesと分かれており、txBytesは秒間送信バイト数で、rxBytesは秒間受信バイト数を表しています。 (※単位はMbpsではなく、Mbytes/secなのでご注意くださいね)
トラフィックも同じく、totalの値を見ることができます。txBytesのtotal値は、各サーバーの秒間送信トラフィックの合計値なので、ILBの秒間トラフィックとも解読できます。今ままではIDCFクラウドのビリングより合計転送量のみ確認できましたが、今後は秒間トラフィックも確認できるのでとても便利です!

これで、ILBに対してのMackerelの導入は完了となります。監視ルールでもこれらのメトリックに対して設定を行えます。

さいごに

ILBのリソース状況が知りたい!という時は、ぜひこの記事に沿ってMackerelをインストールしてみてください。メリットは先ほどもありました通り、以下3点です。
1) 簡単かつ無料?
2) 見やすい?
3) 新規/既存のILBどちらも適用可能?

Mackerelについては以前もたくさん紹介してきましたが、毎日進歩しています。IDCFクラウドとも非常に相性がいいので、ぜひ仮想ルーターやホスト監視などでも活用してみてください。

IDCFクラウドのGPU搭載仮想マシンを使い始める手順~CUDAインストール編~

2016年11月25日、IDCFクラウドに新しいリージョンが追加され、あわせて「GPU BOOSTタイプ Tesla M40」がリリースされました。 www.idcf.jp

ディープラーニング等、通常のCPUでは計算性能が足りなくなるシーンでの利用を想定したGPU搭載仮想マシンです。本記事では、GPUを使い始めるための手順について紹介いたします。

f:id:kkamiyakenshiroh:20161207155756p:plain

1. GPUコンピューティング

GPUコンピューティングとは

主に3DCGなどの画像処理を行うデバイスであるGPUを、計算分野で利用することをGPUコンピューティングといいます。 昨今の「ディープラーニング(深層学習)」「ビッグデータ」「IoT」「AI(人工知能)」「機械学習」など注目ワードには、GPUコンピューティングが密に関係しています。

なぜGPUを利用するのか

CPUとGPUは、それぞれ下記の特徴をもちます。

  • CPU:数コア~数10コアを持ち、逐次処理が得意
  • GPU:数百コア~数千コアを持ち、並列処理が得意

このそれぞれの特徴を活かして、逐次処理をCPU、並列処理をGPUに割り当てることで、CPU単体よりも圧倒的な速度で演算することができます。

2. IDCFクラウド GPU BOOSTタイプの特長

大容量GPUメモリ搭載のGPUを採用

「GPU BOOSTタイプ Tesla M40」は名前の通りNVIDIA Tesla M40 (24GBメモリ版)を搭載しています。ディープラーニングなどのGPUを用いた計算では、GPUメモリ容量がボトルネックになりやすいため、Tesla M40の中でもGPUメモリが多い24GB版を採用しています。

専有タイプで他仮想マシンからの性能影響無し

GPU BOOSTタイプは1物理サーバーに1台だけ仮想マシンが稼働する占有タイプとして提供しているため、共有環境で発生しうる、他の仮想マシンからの負荷による影響を受けず、物理サーバーの全性能を使う事が出来ます。

IDCFクラウドの通常の仮想マシンと同じ操作で利用可能

GPU BOOSTタイプは通常の仮想マシンと全く同じ操作で作成・削除などが実施できます。また課金についても上限金額ありの従量課金となっております。ただし、ハードウェア占有タイプである事と、GPUを仮想マシンに直接認識させているため、以下の制限があります。

  • 仮想マシンが起動した状態でのボリュームのスナップショットの取得ができません
  • 物理サーバーが故障などで停止した場合の別サーバーへのフェイルオーバー機能はありません

3. GPUを利用するためのCUDAライブラリの導入方法

Tesla M40などのNVIDIA社製GPUを用いて計算を行うためには、GPUのドライバと計算を行うためのCUDAライブラリを導入する必要があります。本記事では、IDCFテンプレート「CentOS 7.2 64bit」仮想マシンを前提に、CUDAライブラリのインストール手順を解説いたします。

GPU BOOSTタイプの仮想マシンの作成

GPU BOOSTタイプは現時点では「東日本リージョン2(jp-east-2)」でのみ提供しています。そこで、仮想マシンを作成するためにIDCFクラウドのポータルから東日本リージョン2のコンピューティングを選択します。

f:id:anikundesu:20161201114304p:plain

次に、仮想マシン一覧画面から「仮想マシン作成」をクリックします。

f:id:anikundesu:20161201114340p:plain

仮想マシン作成画面で、ゾーンを「weber」もしくは「lux」を選択し、次の「マシンタイプ」で「GPU」タブをクリックします。するとマシンタイプ一覧に「gpu.7XLM40」が表示されるので、選択します。

f:id:anikundesu:20161201114521p:plain

以後は通常の仮想マシンと同じように設定します。ここではテンプレートとして「CentOS 7.2 64bit」を利用して、設定を確認の上で作成を実行します。

CUDAインストール用のレポジトリRPM取得とインストール

NVIDIA社のCUDA Toolkit配布サイトから、次の図のようにOS等を選択します。そして図内の「rpm (network)」をクリックし、RPMをダウンロードします。

f:id:anikundesu:20161129201908p:plain

ダウンロードしたRPMをGPU BOOSTタイプの仮想マシンにアップロードし、以下のコマンドでインストールを行います。

$ sudo rpm -i cuda-repo-rhel7-8.0.44-1.x86_64.rpm
警告: cuda-repo-rhel7-8.0.44-1.x86_64.rpm: ヘッダー V3 RSA/SHA512 Signature、鍵 ID 7fa2af80: NOKEY
(以下省略)

CUDAライブラリのインストール

CUDAおよびNVIDIAドライバを配布するレポジトリ情報が登録されたので、次はCUDAのインストールを行います。

$ sudo yum clean all
読み込んだプラグイン:fastestmirror, remove-with-leaves, show-leaves
リポジトリーを清掃しています: base cuda epel extras updates
Cleaning up everything
Cleaning up list of fastest mirrors

$ sudo yum install cuda
(以下省略、大量のパッケージが導入されます)

万一、パッケージのダウンロードやインストールが一部失敗するようなことが発生した場合は、yum clean allから再インストールをもう一度実行します。インストールが無事に完了したら、仮想マシンのOS再起動を実行します。

GPUが認識された事の確認

NVIDIAドライバが導入され、正常に認識されると、nvidia-smiコマンドでGPUのステータスが確認できます。

# nvidia-smi
Tue Nov 22 15:00:36 2016       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 367.48                 Driver Version: 367.48                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Tesla M40 24GB      Off  | 0000:03:00.0     Off |                    0 |
| N/A   39C    P0    60W / 250W |      0MiB / 22939MiB |    100%      Default |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID  Type  Process name                               Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

なお、正常にGPUが認識されていない場合は、以下のようなエラーが表示されます。

# nvidia-smi 
modprobe: FATAL: Module nvidia not found.
NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.

再起動後も上記のエラーが表示された場合、もう一度OS再起動をすると認識される場合があります。

以上でGPUを利用するためのCUDAライブラリの導入が完了しました。ディープラーニングで利用するためには、下記のような各種フレームワークを導入する必要があります。

フレームワークの導入に関しては、今後の記事で紹介していきたいと思います。

まとめ

  • ディープラーニングするにはGPUコンピューティングによる強力な計算リソースが必要
  • IDCFクラウドなら、GPU「NVIDIA Tesla M40」搭載の仮想マシンを利用可能
  • CUDAのインストール・フレームワークの導入だけですぐ使える

IDCFクラウド「GPU BOOSTタイプ Tesla M40」のパワーを、ぜひ体験してみてください!

AerospikeをIDCFクラウドで動かすとこんなに良い件

こんにちは、エバンジェリストの藤城(@tafujish)です。

以前にAerospikeのMeetupで登壇させてもらったときに、ブログ書く書く言って長らく書けていなかったのですが、金杉がお試し記事を書いてくれました。

blog.idcf.jp

Aerospikeって何という方はそちらを読んでいただき、ここではAerospikeをIDCFクラウド上で使うのがなぜ適しているのかやベストプラクティスを紹介したいと思います。

続きを読む

最近話題のセキュリティスキャナ Vulsと、Vulsのmeetup Vuls祭り Vol.1のご紹介

こんにちは。Vuls Slackチームに参加している井上です。
IDCFクラウド アンバサダー プログラムでMORIO Dojo ( https://www.idcf.jp/cloud/dojo/ ) にも参加しています(まだ白帯ですね)。

今回、GitHub trending総合で一時的に1位になったこともある、話題の脆弱性スキャナ「Vuls」について、ご紹介の機会をいただきました。

  • Vulsのテスト環境を、MORIO Dojoの縁もあり、IDCFに提供いただきました。ありがとうございます!

  • そのご縁もあり、こちらに寄稿させていただくことになりました。

実機での操作やコードは今回はありませんが、しばらくお付き合いいただければ幸いです。

続きを読む
Copyright © IDC Frontier Inc.