記事掲載

開発者のための実装系WebマガジンであるCodeZineにインフラ本部大山の記事が掲載されました!
アプリケーションエンジニアが活用できるOpenStackプロジェクト「oslo」の紹介、RPCと通知機能を提供するライブラリ「oslo.messaging」の機能と使い方について徹底解説しています。

ぜひ、ご覧ください!!

20161028

 

アプリケーションエンジニアのためのOpenStackライブラリ「oslo.messaging」徹底解説

 

OpenStack

おはようございます。ライトノベル好きのツチノコです。

OpenStack Summit October 2016 – Barcelonaに参加していますので、3日目(10/27)の様子をお伝えします。
3日目はKeynoteがないので、会場の外観です(1日目・2日目と天気がいまいちでようやく晴れのきれいな写真が撮れた)。

ccib

Keynoteがないのでおすすめのセッションです。

Ceph, Now and Later: Our Plan for Open Unified Cloud Storage
Red HatのSage WeilさんによるCephの現状と将来のプランについてです。

重要そうなトピックは3つ。
・(やや古いニュースですが)Ceph Filesystemが安定になりました
Ceph BlockやCeph Objectは”AWESOME”だったけど、Ceph Filesystemも”AWESOME”になったということで会場は盛り上がってました。

・新しい種類のメモリ
そろそろIntel 3D XPointなどのPersistent Memoryのことを考えないといけない時期です。
特性は、Flashと比較してアクセス速度が速いけど容量が小さくて高い。
FlashとHDDの使い分けを考えたように、Persistent Memoryのことも考えましょう。

・新しいBlueStore(=block+newstore) backend
これまでのFileStore backendにかわって新しいbackendになります。Krakenリリースですでにstableとのこと。
どうもErasure Codingでのファイル書き換えなどがこのbackendに依存しているようです。

会場でいろいろ話を聞いていてもみんなCephを使っている感じで、Ceph関連セッションの人の入り方はよかったです。このセッションは本家の発表だけあって満員。
(逆にベンダが製品を押すセッションはがらがら・・・)
OpenStack界隈ではdefaultになりつつありそうです。

こちらもCephを使っているVolkswagenの事例のセッション。
OpenStack and Cars – The OpenStack Journey of the Volkswagen Group

ちょっとサーバ1台あたりの容量を計算してみます。
・Volkswagenの事例では150serversで840TBのCephストレージ。サーバ1台当たりに直して5.6TB/server。
・1日目のDreamHostの事例ではサーバ1台当たり960GB SSDが8本、二重化されてると推定すると3.8TB/server。

Web屋さんの感覚からすると大分大きいですが、社内インフラや各種研究データを抱えようとするとこれくらいが必要なのかもしれません。
1日目KeynoteでもあったようにOpenStackがTechnology Company以外にも適用が進んでいるというのをひしひしと感じます。

おわりに:
3日にわたってOpenStack Summitの様子を少しずつですがご紹介しました。
今回のOpenStack Summitでは、OpenStackはOpenでCollabolativeだというメッセージを強く打ち出していたように思います。
今後もその方針が継続されるとよいですね。

closed

OpenStack

おはようございます。ライトノベル好きのツチノコです。

昨日に引き続きOpenStack Summit October 2016 – Barcelonaに参加していますので、とりいそぎ2日目(10/26)の様子をお伝えします。

2日目もKeynoteから始まりました。Jonathan Bryceさん(OpenStack Foundation)によるMulti-Cloudの話です。

keynote

すでにEU内では複数のOpenStackベースのPublic Cloudが立ち上がっています。

特にヨーロッパではEU外へのデータ持ち出しに関する規制が厳しいため、EU内にデータをとどめておきたい事情があります。
これに対応するため、OpenStackが使ってCloudを作るという選択がされることが多いようです。
(例えばtwitterをEU内から見ると、「Twitterのサービスを利用すると、Cookieの使用およびEU外へのデータ転送に同意したことになります。Twitterとそのパートナーは、アナリティクス、カスタマイズおよび広告目的も含めて、世界中でサービスを提供し、Cookieを使用します。 」という通知が表示されます)

こちらは会場の壁にあったヨーロッパのOpenStackで構築されているPublic Cloudのリストです(Keynoteでも同じものを出して説明していた)。

euro_public_cloud

さて自由にコンポーネントを組み合わせるOpenStackで避けて通れない問題が、互換性です。
このOpenStackで動いているApplicationを他のOpenStackに移せるだろうか?Distributionに(もしくは自分たちのDeployに)ロックインされていないだろうか?は常に問題となります。

それに対するデモの様子がこちらです。
OpenStackの各Distribution(Mirantis, SUSE, Ubuntu, Huawei, etc.,etc.,)で同時にwordpressをdeployしてます。
もちろん、と言える状況がすごいのですが、全員がdeploy成功して会場は盛り上がっていました。

interop_demo

今日のおすすめセッションは以下です。

おまけ: なぜか廊下で行われている #vBrownBag の様子です。

vbrownbag

OpenStack

おはようございます。ライトノベル好きのツチノコです。

早速ですが現在開催中のOpenStack Summit October 2016 – Barcelonaに参加していますので、とりいそぎ1日目(10/25)の様子をお伝えします。
(10/23-10/28のうち、10/25-10/27のメインのSummitに参加予定です)

初日には毎回恒例のMark CollierさんのKeynoteがあります。

keynote_mark

今回のテーマはWorld Runs on OpenStack(#RunsOnOpenStack)ということで、すでにOpenStackは様々な分野で利用されているということにフォーカスが置かれていました。なんとOpenStackの利用者のうち、80%がTechnology Company以外のとのこと。

その代表のひとりとして呼ばれたCERNのTim Bellさん。
Scienceの分野でもOpenStackは利用されています、というかCERNは世界で見ても大きいデプロイのひとつ・・・(CERNのOpenStackブログ)

keynote_cern_tim

さて、Markさんのお話で発表された重要なニュースですが、OpenStackのロゴが新しくなります。flat-designになります。
こちらは会場で見かけた新ロゴの写真です。

openstack_new_logo

みなさん気になるセッションはすでに動画を見てらっしゃると思いますが、面白かった or 役に立つセッションを紹介しておきます。

  • Deploying OpenStack with Neutron and Ceph: From Concept to Public Cloud (and Hell in the Middle)
    • DreamHostのデプロイ例
    • 当初想定: Storageを重要視してCephを選択、顧客がコア数を要求するのでAMD Processorを選択
    • ベータやってみて: HDD遅いし壊れる、顧客はコア数ではなく周波数を要求
    • 今のデザイン: 全部SSDでComputeとStorageが同居するConvergedに、Intel Processorを選択
  • Monasca: One Year Later
    • Monascaがうまれて1年が経ちましたというProject Update
    • そのうちZabbixやnagiosにとって代わる日が来るんでしょうか
  • Message Routing: A Next-Generation Alternative to RabbitMQ
    • MQのBrokerは遅いしScaleしないからRouterにしよう、という内容
    • BrokerがいったんメッセージをQueueに入れるのに対して、Routerはメッセージの宛先を見てQueueに入れずに送る

ほかにも面白そうなセッションありましたが時間が被ってて聞けなかった・・・・

それではまた、2日目の記事でお会いしましょう。

StackStorm

 インフラ本部の大山裕泰です。今回は Brocade が買収したことで話題になった、イベントドリブンな Workflow エンジン StackStorm が一体どういう仕組みで動作しているか、ちょっと深堀した内容をお届けします。

 StackStorm 自体については、先日行われた StackStorm 勉強会で 発表された方の資料 で詳しく解説されており、使い方についても こちらこちら のページで詳しく解説されています。
 「StackStorm を使ってみたけど、裏側で何がどうなっているかイマイチよくわからん」といったユーザ向けに、StackStorm の論理構造を解説し、StackStorm の理解の手助けが出来ればと思います。

StackStorm について

 StackStorm のドキュメント を冒頭から読んでいくと、いきなり次のような図が情報します。

 一見とても複雑そうです。ターゲットに紐付く依存関係を解決してコマンドを実行する “古典的なワークフローエンジン” とは違います。
 初めて触るユーザや、とりあえず QuickStart だけやってみたユーザにとっては、なんでこんな複雑な機構なんだろうかと戸惑われたかもしれません。
 本エントリではこうしたユーザ向けに、StackStorm の概要についての理解と、上記の内部アーキテクチャの詳細についての理解の中間的な論理構成の理解を手助けする内容を提供していきます。

StackStorm の論理構造

 以下は、StackStorm がイベントを処理する仕組みについて表した図になります。

 Sensor は外部で発生したイベントを監視するモノで、外部のイベントを検知した際には予め登録された Trigger にイベントの発生を通知 (以降では “Trigger を引く” と表現) します。
 Trigger は Sensor から通知された外部イベントを Action が扱い易い形に正規化します。何も設定されていない状態では、Sensor が Trigger を引いても何も発生しません。Trigger が引かれた際にどういった処理 (Action/Workflow) を実行するかを規定したものが Rule になります。
 Rule には二つの役割があります。一つは上述した Trigger と Action/Workflow を紐づける役割で、もう一つが Trigger パラメータと Action パラメータを変換する役割です。
 StackStorm では Trigger と Action はそれぞれ独立しており、Rule によって任意の Trigger と Action を組み合わせることができます。その際、Trigger から渡されるどのパラメータを抽出し、どういったパラメータを Action に渡すかの設定を Rule に記述します。

 以下の具体的なケースに置き換えて考えてみます。

 ここでは Sensor, Trigger, Action にそれぞれ以下を使用し、GitHub の特定のリポジトリで Issue を作成(更新)した際に RabbitMQ にメッセージを送る仕組みになります。
 尚、StackStorm では Sensor, Trigger, Action を機能毎にまとめたソフトウェアコンポーネントのことを pack と呼びます。そして、上記の github は rabbitmq のようなサードパーティの pack は (本エントリ執筆時点では) StackStorm/st2contrib リポジトリで管理する運用になっています。

 Sensor ‘github.GithubRepositorySensor’ は 30 秒毎に GitHub のリポジトリの更新状況を確認し、前回の確認から更新が発生した場合には Trigger ‘github.repository_event’ を引きます。
 ここでは、この Trigger が引かれた際に Action ‘rabbitmq.publish_message’ を実行する Rule ‘example.github_event_invocation’ を記述しました。この Rule の内部で Trigger パラメータ (Issue に対する操作(opened/closed)、及びタイトルと本文) を Action パラメータ (exchange, routing-key, message) を次のように変換しています。

動かしてみる

 確認する GitHub のリポジトリは、GitHub pack の設定ファイル ‘/opt/stackstorm/packs/github/config.yaml’ で指定します。以下に設定ファイルの全文を示します。

 ここでは、この Trigger が引かれた際に Action ‘rabbitmq.publish_message’ を実行する Rule ‘example.github_event_invocation’ を記述しました。以下が設定したルールの全文になります。

 ’trigger’ / ‘action’ のパラメータで、それぞれ図の Trigger / Action を指定します。’action’ の ‘parameters’ で当該アクションに渡すパラメータを指定します。ここで Trigger から渡されるパラメータと Action パラメータの変換処理を行っています。
 ’criteria’ パラメータは、Trigger に通知されたイベントのうち Action で処理するモノを選択する際に利用します。今回の例では Trigger はリポジトリに対する Issue の更新/コメント、Fork、Watch、Push などのイベント発生時に Sensor によって引かれますが、Issue の更新イベントだけ Action を呼ぶようにしたい場合にこのように設定します。

 それでは実際に GitHub リポジトリ に Issue を作成し動作を確認します。RabbitMQ に通知された メッセージを受け取るスクリプト を実行し、リポジトリに以下のような Issue を作成します。

 こうすることで Sensor が検知したイベントを Trigger に通知し、Rule に沿って RabbitMQ にメッセージが送られます。そして、先ほど実行したスクリプトで送られたメッセージを取得できることが確認できます。

PAGE TOP