クラウド運用について気づいた６つのこと

きょう、日本MSP協会の記念すべき第１回の会合に参加させていただき、たくさんの議論のなかで、気付き（というか思いつき）が幾つかあったのでメモしておきます。

運用は Managed それとも Operation

"運用でカバー" という言葉が示す通りとかく運用担当は雑用係になりがちです。そもそも運用とは何か？という問いかけに明確に答えられないのが実情だと思います。手順書をもらって作業するのが運用ということになりがちです。
これはただの operation だと思います。
operation を超えて Managed になるには何が必要なのだろうか? という問いかけに答える必要があります。

サービスカタログの必要性

Managed として認めていただくためには、 Managed Service として何が提供されるのかを明確にする必要があると感じました。そのためには Service Catalogue の充実が必要になると思いました。では Service Catalogue の内容として何が必要なのでしょうか? 幾つか思いつきですが並べてみます。

コスト最適化

MSP という業種は Managed 業務のアウトソーシングだと思います。アウトソーシングである以上、自社でやるよりもコストメリットがあることを訴求しなければいけないと思います。そのためにはサービス内容を貨幣価値で評価する必要があり、管理会計的な手法や、オペレーショナルリサーチ的な手法が必要になるように思います。同一コストであれば、デリバリーされる内容が自社運用するよりもレベルが高いとか、同じサービス内容であればコストが安いことなどをお客様や経営層に訴求する必要があると思います。

IT 統制の重要性

Managed Service の重要な課題となるのは IT 統制、特にセキュリティへのコミットメントではないでしょうか。本当に IT 統制を適用するとシステムの規模によりますが、それだけで莫大なコストがかかります。MSP に任せれば セキュリティを含めて IT 統制、コンプライアンスは万全だと言われるような Service Catalogue の整備が必要だと思います。

運用設計の重要性

DevOps ではないですが、クラウド時代の運用は自動化手法が重要になってくると思います。そのためには、システム設計の段階から運用、コンプライアンスに関して重要なアーキテクチャを提案する必要があると思います。例えば、Immutable infrastructure 化する手法の提案などがあると思います。とりあえず作っちゃったから、あと運用よろしくでは IT 統制のコンプライアンスを取得するのは難しくなると感じました。

職業的ディシプリン（規律）の確立

IT 統制の中で最もリスクが高いのは、某通信教育会社の事例を引き合いに出すまでもなく、Human Factor だと思います。MSP に任せて安心だと思っていただくためには、マックス・ヴェーバーの「プロテスタンティズムの倫理と資本主義の精神」ではないですが、やはり倫理的な規範を示す必要があると思います。その規範の表明としてMSPチャーター（憲章）のようなものを制定する必要があるように思います。MSPチャーターに従うことが運用プロフェッショナルとして表明することなるようになったらいいなぁと思いました。

以上、とりとめもなく書いていますが多くの方のご意見を賜りたいと思います。

iproute2 の ss コマンドのバグと、Red Hat Enterprise Linux と CentOS と OSS

「 ssコマンドはバグと地雷の塊なのでnetstatの代わりにならない 」（ここから）というブログのエントリを読んでいて、物事にはいろいろな見方があるのだなぁ。と思ったので感想。

上記ブログエントリでは、「netstat の代わりに ss コマンドが RHEL7.0 で推奨になっているけれど、ss コマンドに "-a" コマンドを付与した場合、UDP のソケットを TCP として報告してしまうバグがあるから使い物にならないよ、みんな注意してね。」という内容。

このバグはRed Hat 社的には 、2014年2月11日に "Bug 1063927 - ss reports udp sockets as tcp" として報告されていて、現在のステータスは "assigned"になっている。 コメントから、現在の7.0では取り込みが間に合わなかったことになっているが、ステータスとしては、"assigned" のままなので、今後のリリースで取り込まれる可能性が十分にある。

コミュニティーには、2014年2月10日にコミットされているので、Red Hat 社としてもコミュニティーをウォッチしていて、可能であればバグフィックスを取り込もうとしている姿勢が見受けられるがいろいろな大人の事情で取り込みまでに時間がかかるのは仕方がない。

というよりは多分、Red Hat 社的には取り込まざるを得ないだろうと思っている。なぜなら、Bug 1063927 は Bug #1039625 -> Bug #1049459 -> Bug #1055607 という三つのバグをブロックしていて、この三つの Bug はいずれも非公開になっている。

オープンなはずの Bugzilla で非公開の Bug があるのは奇異な感じがするが、実際は Red Hat 社の特定顧客から、Customer Portal を通じて報告された Bug は、非公開として Bugzilla に登録される。Red Hat 社は 顧客から依頼された修正は、基本的には取り込まなければいけないので、おそらく 7.1 以降で取り込まれるのだろう。

ただバグも仕様になってしまう、つまりバグ修正をすることによってむしろ非互換が発生すると判断された場合はその限りではないので、難しいところだ。

Cent OS を利用している人は 何も言えないが、お金で解決してしまう Enterprise な世界である。

お金を払って、問題のある製品を提供するのか?という方もいるかもしれないが、Red Hat 社の提供しているのは、QA と 保守なので、QAで対応できなかった問題は保守で対応する。

そもそも Enterprise なシステムは、RHEL 7.0 をいきなり本番適用したりは絶対にない。それがよいかどうかの是非はおいておいて、Enterprise なシステムでは、設計からカットオーバーまで数年近い時間をかけてシステムを構築する。運用期間を含めたら10年以上に及ぶこともあるので RHEL のサポート期間は今や10年以上になっている。（参考:Red Hat Enterprise Linux のライフサイクル）

RHEL 7.0 から検証を始めて、自社に必要な修正を Red Hat 社に取り込ませ、実際に運用開始は 7.3 から開始みたいなことを普通に行う。 本当に Enterprise なことをやっている人たちにはこれは単に課題管理であって、Red Hat がダメだとはならない。むしろ修正してもらえるかどうかわからないことの方が大問題なのである。そのために大金を払っている。

そもそも、バグ自体はメインストリームで修正されているので、自分でパッチを当てたバージョンを作って、とりあえず急場をしのぐというアプローチも考えられる。ただ本当に、Enterprise な環境だと、パッチの管理をどうするかとか、そのパッチ自体に問題があった場合の責任はとか、いろいろ問題が生じるので、そのあたりをお金を払って、Red Hat にやってもらっているのである。

普通の感覚だと、Red Hat 社 のサポート料は高額に見えるが、自社で SE を雇って、QAを行い、場合によっては調査を実施して等などの諸費用を考えると、多くの場合 Red Hat 社にサポート料を払ってやってもらった方が安くなる。

一方で Red Hat 社では、世界中から寄せられる無理難題に対して応え続けた結果、今では結構なナレッジが蓄積されている。そう考えると、サポート料は情報に対する対価という意味合いも含まれている。

じゃあこういった情報を無料で使う方法が無いかというと、そうでもない。 Fedora を使うという方法がある。 Fedora は RHEL の先行リリースという側面があるので、Red Hat の Bugzilla に報告すると回答がもらえる場合がある。場合によっては修正が提供される場合もある。

ただし、新機能の積極的な取り込みが行われるので、人柱になってしまうリスクというかコストが発生するが自分で全部テストしたり、パッチを管理したりするよりははるかにましだ。

ところで、この BUG を追いかけていて、いろいろおもしろかったのは、"-a" オプションの取り扱いがいろいろ紆余曲折を経いていることだ。 （Bug 829632、Bug 829630、Bug 811219 など）

もともと "ss" コマンドの仕様としては、"-a" で tcp しか表示しなかったようだ。(Bug 829630)
これは "-a" の仕様が "Listening" と "non-Listening" を表示するとなっていたのと、ソケットのタイプのデフォルトが、"tcp" になっていたからと説明している。がnetstat との互換性を考慮して修正されている。これが正しいのかどうかはやはり議論が必要だが、少なくとも netstat の出力に慣れた人にはよかったのだろう。

また、ここで新たな問題が発生する。両方表示するようにしたものの、そもそも tcp を表示する前提だったので、"tcp" と "udp" の区別を表示しなかったのだ。(Bug 829632)

これはさすがにまずいので、機能追加されている。そして今回の問題。つまり Bug 829632 の機能追加漏れになる。なかなか一度にすべての機能がそろわないという実例。

まさに Bug 1063927 のコメント 1 にある通り、"The `ss' utility needs a lot of love"  な状態である。net-tools じゃなくて、iproute2 じゃないと、機能不足なことも多々あるので、今後の進展に期待したい。

OSS なので、様々な考え方や実装があっていいと思う。明確な仕様書が無い世界なので、一般的に合意された動作になるのが正しいと思う。 ”一般的に合意された” 動作になるためには公の議論が必要で、そのためにはMLや公開の bugzilla 等で意見を表明していくのが良いのではないだろうか。

そうでないと "RHEL" やそのクローンである "CentOS" の呪縛から逃れることができない。

SELinux モジュールの中身を確認する

Serverfault 経由

How do I view the contents of a SELinux policy package
http://serverfault.com/questions/321301/how-do-i-view-the-contents-of-a-selinux-policy-package


postgreylocal.mod から、postgreylocal.pp を取り出す。

semodule_unpackage postgreylocal.pp postgreylocal.mod

semodule_unpackage はここにある。

postgreylocal.pp から ルールを取り出す。

dismod postgreylocal.pp

dismod はここにある。

本来は、checkpolicy 等のテスト用らしい。

Amazon zocalo の public preview が登録できたので使ってみた。

Amazon Web Service (AWS) から、新しいサービス Amazon Zocalo （ソカロと読むらしい）が登場しました。zocalo は台座の基底部という意味らしいです。現在 Public preview となっており、使用に当たっては事前に登録が必要です。

基本的には、BOXや、DropBox などと同じファイル共有の仕組みです。他のアカウントとは全く関係ない、任意のアカウントを登録して使うことができます。

何となく申し込んでおいたら、OKが来たので実際に使ってみました。

登録完了のメールのリンクをクリックしていつものマネジメントコンソールからログインすると、以下のような画面が表示されます。

特に迷わず "Get Started Now" をクリックします。するとQuick Start と Standard Setup が選べますが、この手のツールは難しいことしたら負けなので、"Quick Start" を選びます。

次にURLと管理者の登録画面になります。特に難しい入力項目もないので、適当にURLとメールアドレス、名前を入力して"complete setup" をクリックします。URLは後で共有するときに利用します。

画面が変わって "Initializing" となります。10分ほど待ちます。

ちょっとまってリロードすると、"Active" になりました。

先ほど登録したメールアドレスにパスワード変更用のURLが届きます。

Get Started をクリックして、パスワードを設定します。

パスワード以外は登録時の情報が入力されています。パスワードの制限は以下の通り。

少し待つとWelcome の画面が表示されて利用可能になります。

とりあえず ×してWelcome 画面を閉じると利用可能になります。 Review 機能等がありお仕事で利用する文書を管理するときには便利そうです。

Administration をクリックして管理画面を表示します。

Invite Users をクリックして共有するユーザーを指定します。ユーザーは一度に複数指定できるようです。

追加したユーザーに先ほどと同じパスワード変更依頼のメールが届くので、パスワードなどを登録してもらいます。以上で準備は完了です。

既にApp Store や Google Play に モバイル用のアプリも登録されているようですが、Apple 用は iPad にしか対応しておらず、私の スマフォ は未対応となってインストールできませんでした。

基本的にタブレットしか対応していないようです。

気になるお値段ですが、月200Gで$5 です。ファイル共有だけならば、S3よりもずっと簡単です。l

今後スマフォ等の対応が広がれば個人的にはファイルサーバを構築する必要はないように思います。AD連携ができれば、もっといいかもしれません。

Amazon Web Service (AWS) EC2 に新しく T2 インスタンスファミリーが加わりました。

Amazon Web Service (AWS)  のコンピュートサービスであるEC2 に T2 インスタンスファミリーが加わりました。これまでの m1.small や t1.micro を置き換えるものです。

正直 t1.micro は無料利用枠が利用できることもあり、よく利用していましたが若干力不足があったのは確かです。ちょっと大きなビルドを通そうとすると、すぐにメモリ不足でビルドが失敗していました。

新しい t2 インスタンスファミリーは以下の3つのインスタンスタイプです。

インスタンスタイプ	vCPUs	メモリー (GiB)
t2.micro	1	1
t2.small	1	2
t2.medium	2	4

うれしいのは、搭載メモリが増えたことと、CPU クロックの上限が上がったことでしょうか?

東京リージョンでの時間当たりの価格は以下の感じです。

インスタンスタイプ	一時間の料金
t2.micro	$0.020
t1.micro	$0.026
t2.small	$0.040
m1.small	$0.061
t2.medium	$0.080

t2.small と 同じ1 vCPU の m3.medium が $0.101 ですからぐっとお安い感じです。 また m1.small や t1.micro と比較して、お値段がぐっと安くなっています。 t2.micro は 無料利用枠で利用できるようになっています。

t2 インスタンスファミリーの興味深いところは CPU 性能がバーストすることです。 EBS gp2 と同じく CPU クレジットを受け取り、一定以上のCPU利用率でクレジットを消費します。

インスタンスタイプ	イニシャルクレジット	一時間当たりの補充量	ベースパフォーマンス	最大クレジット残高
t2.micro	30	6	10%	144
t2.small	30	12	20%	288
t2.medium	60	24	40%	576

1 CPU クレジットは、おおよそ1分間 100 % の使用率に相当します。
これまでの t1.micro でのバーストの仕方とずいぶん変わりました。 クレジットの残量は CloudWatch で確認できます。

• CPUCreditUsage
  期間中に消費されたクレジットの量。5分間隔で更新される。
• CPUCreditBalance
  クレジットの残高。5分間隔で更新される。

その他の主な制限事項は以下の通りです。。

• HVM タイプの AMI しか利用できない。
  この制限があるので、現在 VPC NAT インスタンスとして利用できない。
  でもいつの間にか VPC NAT インスタンスで t1.micro が使えるようになっていた。
• VPC 内でしか起動できない。
• インスタンスタイプ毎に起動できるのは20インスタンスまで
• 24時間で起動できるのは100インスタンスまで
• もちろん spot instance もダメ

利用シーンとしては、それほどアクセスの内WEBサイトや、短時間で終了するバッチジョブのような用途でしょうか。
クラウドウォッチでクレジット残高を監視しながら残高不足になるようであれば、他のインスタンスサイズへの変更を検討することになると思います。

Amazon Elastic Compute Cloud User Guide (API Version 2014-06-15) T2 Instances
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instances.html

 Amazon EC2 Pricing
http://aws.amazon.com/ec2/pricing/

Amazon Web Service ブログ
【AWS発表】バースト可能な性能を持つ新しい低コストEC2インスタンス
http://aws.typepad.com/aws_japan/2014/07/low-cost-burstable-ec2-instances.html

OSv を AWS EC2 からアップロードしたメモ

先日どこかのもくもく会で取り上げられていましたが、OS^vという OS があります。 designed for cloud と銘打っておりクラウド向けに最適化されたOSを目指しています。

OS^v is designed from the ground up to execute a single application on top of a hypervisor, resulting in superior performance and effortless management

現代のOSは Linux を含めて、非常に高機能で複雑になっています。
これはオンプレミス上で多様な機器をサポートしたり、さまざまなワークロードに単体で対応する必要があるからです。

一方でクラウドをはじめとする仮想化環境ではハードウェア自体は仮想化され、もともとOSが担っていた多くの機能に関してはクラウドベンダやハイパーバイザが担っているため、ゲストOS側ではミドルウェアで必要とする最低限のインターフェイスだけを残しておけばいいという考え方でOS^vは設計されています。

というわけで、実際にためしてみたいと思います。今回はまずOSのイメージを AWS 上に転送するところから始めて見たいと思います。

手順はここを参考にしました。

AMI の起動

AWS Linux では、いくつかのパッケージが不足しているので、Red Hat (Cent OS) もしくは、Fedora の AMI がお勧めだそうです。今回は私は、RHEL-6.5_GA-x86_64-7-Hourly2 (ami-aa8bfe9a)を利用しました。 普通に起動して、SSH 接続します。RHEL も時間課金で利用できるので、気楽に利用できます。

必要なパッケージ、ツールのインストール

パッケージのインストールから、github からのダウンロードまでやってしまいます。
sudo yum install git
sudo yum install ant autoconf automake boost-static gcc-c++ genromfs libvirt libtool flex bison
sudo yum install qemu-system-x86 qemu-img maven maven-shade-plugin python-dpkt tcpdump gdb
git clone https://github.com/cloudius-systems/osv.git
cd osv
git submodule update --init --recursive


AWS CLIのインストール

wget https://s3.amazonaws.com/aws-cli/awscli-bundle.zip
unzip awscli-bundle.zip
sudo ./awscli-bundle/install -i /usr/local/aws -b /usr/local/bin/aws


同じく AMI ツールのインストール

wget http://s3.amazonaws.com/ec2-downloads/ec2-api-tools.zip
sudo mkdir /usr/local/ec2
sudo unzip ec2-api-tools.zip -d /usr/local/ec2


環境変数の設定 

export AWS_ACCESS_KEY_ID=AKI.........................
export AWS_SECRET_ACCESS_KEY=XXX........................
export EC2_HOME=/usr/local/ec2/ec2-api-tools-1.7.1.0/
export JAVA_HOME="/usr/lib/jvm/jre-1.7.0-openjdk.x86_64/"

EC2_HOME のバージョンは各自確認してください。
AMI ツールは IAM ロール未対応 なので、IAMロールを設定した場合でもアクセスキー、シークレットキーの設定は必要なようです。

実行

ここまでで、環境の準備は終わりです。時間は30分もかからないでしょう。
vim 等のテキストエディタで以下の内容でテキストファイルを作成します。
ファイル名は例えば、"images_0.09.txt" などとします。

v0.09-small
http://downloads.osv.io.s3.amazonaws.com/cloudius/osv/osv-v0.09.qemu.qcow2
small

一行目が作成されるイメージの名前、2行目が元イメージがおいてある URL 3 行目がインスタンスサイズのようですが、内容は未確認です。

cd osv
./scripts/upload-ec2.sh < ~/images_0.09.txt

これでほおっておくと勝手に AMI が出来上がります。時間は結構かかります。
やっていることはおおよそ以下の通りです。

1. イメージをダウンロード
2. qcow2 のイメージを raw イメージに変換
3. イメージを S3 にアップロード
4. S3 上のイメージを EBS に変換
5. 新しいインスタンスを作成して stop する
6. インスタンスの EBS を差し替え
7. AMI を作成する。
8. インスタンスのTerminate

この手順を実施すると、N.Virginia (us-east-1) に public な AMI が作成されます。
きっとリリース手順をそのまま書いたのでしょう。紛らわしいので、私のAMIは削除しておきます。

OSv designed for cloud
http://osv.io/

Upload OSv AMI from EC2 instance
https://github.com/cloudius-systems/osv/wiki/Upload-OSv-AMI-from-EC2-instance

Amazon Elastic Block Store (EBS) General Purpose (SSD) volumes (gp2) の バースト特性

先週リリースされた EBS gp2 タイプですが、これまでのスタンダードタイプよりバースト性能が改善されています。 バーストの仕様についてはマニュアルや公式ブログにかなり詳しく記載されていますが、実際に動作確認を行ってみました。

まずはおさらい

この前の記事にも記載しましたがEBS gp2 のバースト仕様を簡単におさらいしておきます。

• バースト時の最大出力は 3000 IOPS
• バーストの制御方法は、Token Bucket 方式
• Token は容量1GBあたり毎秒3個づつ補給される。
• Token 一個は 1 I/Oに相当
• Token はEBS 1 個あたり最大 5,400,000 個 保存できる。
• EBS作成時は、5,400,000 個 Token が補充される。

今回のテスト環境

今回使用した環境は、m3.xlarge を使用しました。OS側の影響を少なくするために少し大きめのインスタンスを利用しています。I/O 処理する分と、dd が動作する分と、sar と ssh が動く分でCPU 4つぐらいあれば大丈夫かな? という程度の考え方です。

EBS は gp2 タイプ 100 GB 確保して、ブートディスクとは別にインスタンスにアタッチしました。

単純に IOPS がでればいいので、以下のコマンドラインで負荷をかけました。

while true ; do dd if=/dev/zero of=/dev/xvdb bs=4k ; done 

以前はIOPSでの課金があったので、ベンチマークを実施するときはお財布を気にしながらでしたが、EBS gp2 タイプでは従量課金がなくなったので安心して負荷をかけることができます。

プレウォームを実施

EBSは特性上、プレウォームを実施すると全体の特性が良くなります。

今回もプレウォームを実施しました。

実施結果

cloudwatch の VolumeWriteOps の結果です。
CloudWatch では、EBS の IO 数を 5 分間隔で取得できます。
5分間のIO数合計が出力されます。

左から一つ目の山がプレウォーム時のものです。プレウォーム時で5分間に 約 600,000 IO 出ています。60s × 5 = 300 s で割ると、 2,000 IOPS ぐらいです。プレウォームしないと、3,000 IOPS は出ません。 

二つ目の山が、プレウォーム後少しおいて再度負荷をかけた時のものです。大体 800,000 IO 出てますので、およそ 2,666 IOPS です。 3,000 ぴったりにはなっていないですが、大体いい値ではないでしょうか。

その後は大体 300 IOPS で安定しています。

バーストしている時間はプレウォームの期間も含めておよそ30分強でした。これも仕様と大きく離れていません。

復活するか

その後2時間ほど負荷を停止して token がたまるのを待って見ました。満タンになるのに5時間ほどかかってしまうので、2時間ほどでどれだけ復活するか見てみました。

最後の山が復活した時のものです。たしかに停止するとバーストは復活します。ただためている時間が短いので、10分程度しか持ちませんでした。

Token はいつ補充されるのか

Token がどのタイミングで補充されるかはマニュアルに明確な記載がありません。ここからは完全な推測です。

上のグラフは sar で取得した await の出力をEXCEL でグラフにしたものです。

OS 側で取得したのでかなりばらつきが大きくなっています。

間隔は1秒間隔で取得しています。最初の塊がプレウォーム時のもので大体 70-80 ms で推移しています。これは実ブロックの割り当て処理のオーバーヘッドでしょう。

その後暫く休憩して次にバースト時のものです。大体 50-80 ms ぐらいです。

最後に値が大きくなっているのはバースト終了後のもので、大体 480 ms ぐらいです。

バースト時とバースト終了時の差分が大体 400ms ぐらいです。

この差分は、Token が補充されるまでの時間だと予測できます。

おそらく1秒間に3個補充されるのではなく、300数十ms に1個補充されているのではないでしょうか。

それで1秒あたり3個補充されていることになるかと思います。

まとめ

EBS gp2 タイプのバースト特性はおおよそ以下の通りだと思います。

• token がある限り IO を払いだす。
• 3000 IOPS が、おおよその性能上限
• バースト時は結構ばらつきが大そう
• token は、300 数十 ms 毎に補充される 

おまけ

私は個人的には実はIOPSはあんまり気にしていません。

IOが不足しているかどうかの判断は VolumeQueueLength を参考にしています。

もし IO が要求に追い付いていないならば、キューの値が増加して減らなくなります。

もしキューにIOが無いならば、そもそもIO要求が来ていないことになります。

またキューがたまっている状態では IOPS は最高値になっているはずで、それ以上にIOが必要なっていることを示すだけで、余りサイジングの参考になりません。長期的にみて増加傾向ならばその傾向からある程度、サイジングの参考にはなると思います。