本記事に関するお問い合わせ先： /products/privatecloud/index.html

ボストンからこんにちは！
本日も、OpenStackSummit 2017 Bostonのホットな情報をお届けいたします。

OpenStackSummitも最終日の4日目となりました。
本日は興味深かったセッションの情報および、サミット全体の所感をお知らせします。

※なお、本記事の記述は概要に留まります。見聞きしてきたセッションのより詳しい情報は、後日別記事にてご紹介する予定です。そちらもご期待ください！

1日目～3日目の記事は以下です。

・1日目：/column/tec/openstack_summit_2017_boston_1/
・2日目：/column/tec/openstack_summit_2017_boston_2/
・3日目：/column/tec/openstack_summit_2017_boston_3/

■セッション

OSprofiler: Evaluating OpenStack

OSprofilerという、OpenStack向けのプロファイリングライブラリの機能を紹介するセッションです。
OSprofilerは比較的以前から存在するライブラリなのですが、今回改めて概略説明のセッションが設けられるということは、認知度があまり高くないのかもしれません。会場は技術者風の参加者で比較的埋まっていました。
（かくいう執筆者自身も、存在と機能の概略は知っていたものの、本格的に利用したことはありませんでした）

まず端的にOSprofilerに何が出来るかという点ですが、これを利用すると、API等の処理の流れをソースコードの関数レベルで可視化できます。各関数の所要時間も見られるため、例えばパフォーマンス問題があった場合どこで時間を食っているかを調べやすくなります。
VMへのボリュームアタッチのように複数コンポーネントにまたがる処理であっても一つの図として見ることができるとのことです。
また、エラーが起きた場合は、Exception情報も見ることができます。

使い方としては簡単で、基本的には以下となります。

1. OpenStackの各種コンポーネントの設定ファイルの[profiler]セクションでenabled=trueにし、他に各種設定を行う。このとき、hmac_keyはコンポーネント間で同一の値にする。

2. OpenStackの各種CLI実行時に、「--profile <設定ファイルのhmac_keyの値>」オプションを付与する。すると、通常のCLI出力に加えて、プロファイル情報のIDが出力される。

3. osprofilerコマンドで2で得たIDを指定してプロファイル情報を出力する。出力形式は、HTML・JSON・DOTから選ぶことができる。

注意が必要なのが、上記は全てのOpenStackコンポーネントが対応しているわけではない、ということです。
とはいえ主要なコンポーネントは既に対応済みとなります。具体的に、現状対応しているコンポーネントは以下とのことです。

・Nova, Neutron, Keystone, Cinder,, Glance, Heat, Horizon, Trove, Zun, Mistral, Magnum, Zaqar

※Murano, Ironicも対応予定で現状レビュー中とのこと。

また、OSprofiler 1.9であれば、プロファイル情報はCeilometer、Elastic Search, Log Insight、Mongo DB、Redisに永続化もできるとのことでした。

セッションの感想ですが、OSprofilerはOpenStackの複雑な挙動を理解・解析するうえで非常に有用な機能であり、今後の業務でぜひ活用したいと感じました。特にNovaのVM起動のように複数のコンポーネントが絡み合うAPIを解析したい場合、OSprofilerは大きな助けとなりそうです。

ただ注意点として、OSprofilerを有効化した場合のオーバーヘッドはゼロではないようで、パフォーマンスを考えるとプロダクションレベルの環境で有効化するのは検討したほうが良いようでした。
永続化する場合にデータ保存先がクラッシュした際の挙動等も気になるところであり、本番環境へ導入したい場合は、検証を行ってからのほうが良いでしょう。

DOT形式の出力をグラフ化したデモの様子です。

OpenStack Cluster Zero-Downtime Upgrade with Kolla

通常、OpenStackをUpgradeするときはサービスへの影響をできる限り小さくすることを考えます。
このセッションではデータベースUpgrade時のダウンタイムをゼロにする手法を提案していました。

まず2つの案を紹介していました。

案1．「Requests Buffer」を用意し、新たなリクエストはこのバッファにたまる状態にしてDBスキーマをMigrateする
　　→欠点：Migrateに要する時間が長くなるとRequenstがタイムアウトしてしまう可能性あり

案2．データベースのチェックポイントを作成、またバイナリログの出力設定を行い、更新されないデータ(currentDB)と、その後の更新データ(newData)を分けて、currentDBのスキーマMigrate後にバイナリログを使ってnewDataをMigrateする。
　　→欠点：サービスを一度停止しなければ(短時間で良いが)upgradeできない

その後、欠点を補うために２つを組み合わせた以下のような手法を提案していました。

・チェックポイント作成・バイナリログ出力設定
・currentDBをMigrate
・案1のバッファ機能をオン
・newDataをMigrate
・バッファ機能をオフ

この欠点を補った手法のPoCをKollaによって実現しているようです。
デモが予定されていたのですが残念ながら画質トラブルで見られませんでした。

DBの冗長構成をとっていない場合、何かしらの対策をとらなければ一度サービス停止することになってしまうので今回の案が実装されれば利用したいというユーザも多いのではないかと思います。
気になったという方は今後のKollaの動向や本セッションの動画をチェックしてはいかがでしょうか。

■サミット後

サミット後は、恒例となった感のある、日本からの参加者向けパーティーに出席してきました。

なんだか不思議な話ですが、国内では普段顔を合わせる機会のない方々と、日本から遠く離れた海外でお話しできる貴重な機会であり、今回も非常に有意義な時間を過ごさせていただきました。

もし本記事を読まれている方で今後OpenStack Summitに参加されるということがありましたら、ぜひこちらのパーティーにもご出席されることをお勧めいたします。

■OpenStack Summit 2017 Boston全体の所感

今回のOpenStack Summit 2017 Boston全体の所感として、近年の傾向にもいや増してコンテナ......それもKubernetes + dockerを絡めた話題が非常に多いサミットでした。
キーノートのデモも多くが上記に依拠していましたし、とあるセッションでは講演者が冗談で「Kubernetes Summit Bostonにようこそ！」と切り出していました。
また、コンテナ関連ソフトウェアは他にも種々存在しているのですが(Mesos等)、もはや特に説明もなくこの組み合わせを採用しているセッションも多く、もはやデファクトスタンダードと化している感がありました。

OpenStackとコンテナを組み合わせる際の利用方法としては、大きく分けて「OpenStackでデプロイしたVMやベアメタル上でコンテナを運用する」パターンと「OpenStackプロセス自体をコンテナとしてデプロイする」パターンの2つがあるのですが、今回のサミットではいずれのパターンもよく見かけました。
前者については、継続的デリバリツールSpinnakerも組み合わせるなど、更に一歩踏み込んだ利用の紹介も多くありました。

また、コンテナで資源を最大限効率的に利用するため......ということなのでしょうが、ベアメタルプロビジョニングがこれまでになく注目されており、今後はIronicが脚光を浴びていくかもしれません。

なお、コンテナ関連のOpenStackコンポーネントというと、MagnumとZunがありますが、Magnumは今回不憫に感じるほどセッションで名前を見かけませんでした。
反面、新顔のZunはちらほら名前を見かけるようになっており、今後さらに勢いを増していくかもしれません。

■おわりに

4日間にわたるOpenStack Summit 2017 Bostonの現地報告、いかがでしたでしょうか。
OpenStack界隈のホットな状況が伝わりましたら幸いです。

当社は今回のサミットで得た知見も活かし、OpenStackビジネスをより強力に進めていく所存です。
もし何らかご興味ご関心お持ちでしたら、冒頭の連絡先にぜひご一報ください。