HDE BLOG

コードもサーバも、雲の上

はじめての障害演習

どうもこんにちは。 Account Management Section の服部/安孫子がお送りします。

みなさんは自社が提供しているサービスに障害が起きた場合の備えは万全ですか? 特に大規模な障害が起きてしまった場合、構築している体制で迅速な対応ができますか?

今回は、弊社内で実施した HDE Oneサービスの障害対応演習について企画者の一人として書いてみたいと思います。

演習実施に至った背景

過去に発生したHDE One サービスにおける障害発生を機に、再発防止のシステム改善と強化だけではなく、社内オペレーションの見直しと障害のケーススタディを行い、対応の練度をあげる必要性が社内で議論されていました。

また、障害発生後にご契約いただいているお客様を対象としたアンケート結果からも、「情報公開」「連絡頻度」「対応スピード」について多くのご意見をいただきました。 そこで社内にプロジェクトチームを立ち上げ、取り組みの第一弾として障害対応演習を実施することになりました。

目的の再確認

第一回である今回は、演習用のクラウド環境などは準備せず、障害発生時の人のオペレーションと課題抽出、コミュニケーション強化をテーマとしました。 訓練も机上演習ながら長い時間を使って演習を行う都合上、週末に実施することに決定しました。

f:id:hde:20150622205801j:plain 初期の議論のホワイトボード

企画:真面目さと遊びココロのバランス

目的はきっとメンバーにも理解してもらえるでしょう。

でもお題目として理解してもらっても意味はない。

参加メンバー全員が当事者意識と危機感をもって参加してくれなければ、わざわざ週末にまで出社して演習をやることはないと考えていました。 そこで、まじめにやる部分と楽しんでもらう部分のバランスに心を砕きました。

大まかな構成は以下の3部構成。 ①レクリエーション ②ディスカッション ③障害演習

実は、一番早くディテイルが決まったのが①の部分です。内容は「人狼村からの脱出」というリアル脱出ゲームを開催しました。 f:id:hde:20150622205822j:plain

障害対応のポイントは何度も議論を尽くしたのですが、対応のリーダーシップと役割分担、社内での円滑なコミュニケーションなどのポイントが上がりました。 このゲームは挙がってきたポイントをほぼ全て押さえられるものと判断し、企画のメンバーでテストプレイをしてみて実施を決定しました。

以下、演習当日のハイライトをお送りします。

実際の演習の様子

f:id:hde:20150622210801j:plain 演習開始:

f:id:hde:20150622210756j:plain 午前の部:チームビルディング(人狼村からの脱出)

実際のプレイでは、写真のように準備された資料を解いていく事で人狼を突き止め、人狼村から脱出することがゴールです。

f:id:hde:20150622205825j:plain 午前の部:ディスカッション 過去の経験から改めて障害対応で何が大切になるのか、各メンバーから意見を出してもらい、発表してもらいました。

f:id:hde:20150622205812j:plain 午後の部:障害演習

プロジェクトチームが用意したケーススタディを元に、4チームに分かれて割り振られた障害に対しに最適な行動を決定し、質疑応答のなかでさらに議論を深めていきました。

刻一刻と変化していく状況にどう対応すべきか議論していく中で、チームが取り組んでいくべき課題がいくつも見つかったことが大きな成果でした。

想定した障害の中には HDE One サービス全体がそもそもダウンしたらどうするか、障害発生時の状況の中には対応すべきメンバーが全員対応不能な状況になっているなど想像するのも恐ろしいものも含まれていました。

f:id:hde:20150622205832j:plain 午後の部:ディスカッション

第一回の演習で得た気付きは以下の通りです。
- 障害とは何か、障害対応とは何か、当事者間での意識統一の重要性

- 迅速かつ確実な対応を両立させる体制構築の重要性

- 演習の定期実施の必要性

- 社内全体を巻き込んだ情報共有や訓練実施の検討

メンバー全員が高い当事者意識を持ち、お客様に満足いただけるサービスとは何か、という点を真剣に議論する姿が印象的でした。 今後の演習ではクラウド上構築した演習環境を使っての演習実施を計画しています。

f:id:hde:20150622205805j:plain 最後は打ち上げ、みなさんお疲れ様でした!

偶然にもこの日は、我らがセクションのボスでもある副社長宮本がもうすぐ誕生日でしたのでお祝いをしました!

f:id:hde:20150622211103j:plain ボスとケーキ:

HDE では弊社サービスを安心してご利用いただけるよう、チーム一丸となってお客様をサポートして参ります。今後も弊社の取り組みを本ブログにて皆様に公開して参りますので何卒宜しくお願いします。

以上です。

PandoraFMS を使ってみた

System Consulting & Sales Division の荒川です

先日、社内勉強会にて「PandoraFMS」を発表させていただきました。 発表内容のダイジェストをこちらのHDEブログに書いて欲しいという依頼を頂きましたので ありがたく書かせていただきます。

pandoraFMS とは?

PandoraFMS とは、スペインで開発されているオープンソースの監視ツールになります。 オープンソースの監視ツールとしては、Naigos や Cacti 、 Zabbix などが有名ですが、 PandoraFMS はどちらかというとマイナーな部類になると思います。

(結構知られていると思ったのですが、社内勉強会では、「どこで見つけてきたの?」 的な質問が多く寄せられたので、マイナーな部類だと感じました)

また、PandoraFMS はエンタープライズ版(有償)もあり、こちらは使える機能が増えており、 サポート対応もしてくれます。

詳しい違いは、PandoraFMS のホームページにまとめられています。

http://pandorafms.com/Soporte/pricing/jp

なぜ PandoraFMS か

では何故 PandoraFMS を使ってみようと思ったのでしょうか? 監視ツールとしては、Naigos と Cacti を利用してきたのですが、監視の運用負荷を 減らしたい!と思ったことが理由です。

監視の運用負荷

1) システム監視とリソース監視が別システム。

Naigos には、リソース状況を分かりやすくグラフ表示してくれる機能が無い為、 システム監視は Nagios 、リソース監視は、Cacti と2つのシステムを使っています。

Cacti のグラフは見やすく使い易いのですが、新環境の監視を設定する時など、 2つのシステムに設定を行うので面倒だと感じていました。

PandoraFMS では、システム監視とリソース監視が1つのシステムで実現できます。 リソース状況の表示も Cacti と同じようにグラフで見やすく使い易いです。

f:id:ryota0811:20150619152807j:plain

2) そもそも手動で設定したくない。

社内のシステムなど、様々なソフトウェアが動作している環境では、サーバ単位に手動で 監視を設定するしかありません。

しかし、弊社の様にサービスを提供する場合、動作するソフトウェアや導入する監視項目は、 固定できます。監視の導入を自動化することで、工数の削減だけではなく人為的なミスも 防ぐことが出来ます。

PandoraFMS のシステム監視(ネットワーク監視を除く)は、サーバから Push する方式なので、 サーバ構築時に サーバ側に PandoraFMS agent のインストールと設定ファイルを設置すれば 自動で監視が開始されます。

サーバの構築に chef 等の自動化ツールを使用することで、構築から監視までの自動化が 可能になります。

f:id:ryota0811:20150619152842j:plain

3) GUI による管理が便利

Nagios の設定はテンプレートに汎用的な定義を作成し、それを継承する方法で 行いますが、設定ファイルではどのサーバがどのテンプレートを継承しているかが 分かりにくいと感じていました。

PandoraFMS では、管理GUIで通知先などの設定が可能なため、継承関係が分かりやすく、 簡単に設定変更が行えます。

f:id:ryota0811:20150619154941j:plain

まとめ

以上、PandoraFMS について少しは理解を深めていただけましたでしょうか?

PandoraFMS は API が豊富なため、オープンソースでも使い方次第では、 必要な監視を網羅できると考えています。

EIPプールをつくったお話

Service Engineering Division / DevOps Unitの出口です

先日,社内勉強会にて「EIPプールをつくったお話」をユニットの代表として発表させていただきました. 発表内容のダイジェストをこちらのHDEブログに書いて欲しいという依頼を頂きましたので 僭越ながらありがたく書かせていただきます.

DevOpsチームにとってのEIP

メールサービスをお客様へ提供するために リリース作業のなかで新しいEIPを取得し,お客様のテナントと紐付けを行っています

しかしながらただEIPを取得するだけではなく以下の作業(設定の申請)を行わなければなりません

  • メール送信制限の解除申請
  • IPの逆引き申請
  • RBLの解除申請

「なんだたったの3作業か,それぐらい仕事しろよ」と思われるかもしれませんが 実際に作業をしていると以下の問題点が浮上します

  • AWS作業遅れがリリース作業スケジュールに影響を与えている
    AWSの作業遅れによりリリース作業を行うときに時間に余裕を持たせなければいけなくなります

  • 確認作業を行う必要がある
    RBL解除されているかの確認作業を行う必要があります

  • 生身の人間がEIPを操作するのには無理がある
    現状EIPにはタグ等を付けられないので XXX.XXX.XXX.XXXのEIPの申請を間違えてYYY.YYY.YYY.YYYで出してしまった等のミスが考えられます

ということでEIPを貯めておくプールを作りました

これらの問題を一挙に解決するためにDevOpsユニットが頑張ってEIPを蓄えておけるプールを作りました. 簡単なフローは以下のとおりです

  1. 定期的にEIPを「申請解除待ち」状態としてためる
  2. 自動的に申請を出す
  3. 別タスクで定期的にRBL等から解除されているか確認をする
  4. 解除されたことが確認されたら「申請解除」状態にする

また上記フローとは別に以下の機能もつけました (詳しい説明は割愛)

  • ログを残す (基本中の基本)
  • Slack通知機能
  • RBL監視システム

EIP Poolが実装されたよ

そして先日,ついに本番環境へ実装されました

朝のMTG後にJenkinsさんがEIPプールの状態をお知らせする様子がこちらです

f:id:koppe_dd:20150611174115p:plain

現在DevOpsユニットでは最大30のEIPを確保するような設定になっているのですが, 上の図は自由に使える状態(つまり申請が処理されて設定済み)のEIP(緑りんご)が24あり, 申請が処理されるのを待っているEIP(赤りんごとなす)が4つあり, 空いている状態(ふたば)が2つとなっています(こちらの空きは自動的に補填されるようになっています)

ここで地味に注目していただきたいのが「なす」です
この「なす」のマークが付いているEIPは申請は出したけれどなぜか長期(7日以上)経過しても 設定されていないEIPに対してつけられるマークで以前までの環境だと リリース遅延の原因となりうるEIPだったことを意味します

一方でEIPプールを実装した後はすでに確保してある設定済みのEIPを使えば良いため, このようにリリース遅延の原因をなくすことが出来ました.

おわりに

今回ご紹介したEIPプールは自動化に関するほんの一例で DevOpsユニットではEIPプールにとどまらずさらなる自動化やリリース作業の効率化によって日々進化をしつづけています

機会があれば,皆様にDevOpsユニットがどのようにして効率化をしているかご紹介できればと思います. つたない文章でしたが最後まで見て下さりありがとうございます

YAPC::NA 2015 に参加してきました

YAPC::NA は16年の歴史を持つ今夏開催されるYAPC::Asia Tokyo 2015の元となったカンファレンスです。今年はSalt Lake Cityで開催されました。

自分は今年でYAPC::Asia Tokyoに一区切りが付くので、2000人規模のイベントを開催するにあたってどういうところに注意をしながら今まで準備をしてきたのか、などのノウハウをシェアするトークを発表するためと、Perl界隈の人達と旧交を温め、新しいつながりを求めて参加しました。

今年の会場はアメリカはユタ州のソルトレイクシティーです。アメリカには長いこと住んでいましたがユタ州には来たことがなく、初上陸です。ユタ州と言えばステレオタイプ的なイメージでは砂漠やモルモン教なのですが、どちらもその姿を見かける事なく若干拍子抜けでした。ソルトレイクシティーの印象は若干乾いた気候の普通のアメリカの地方都市でしたが、特筆すべき点としてはとにかくアメリカにありがちなただの平たい景色ではなく、町の後ろに雄大な山々が鎮座しているのがとても印象的で美しい景観でした。

Untitled

会場はLittle America Hotelというホテルの一階にあるレセプションルームを使って行われました。大きい500人程度収容可能な部屋がひとつあり、キーノートやLightning Talkの時はその部屋全体を使います。それ以外の時間帯ではその部屋を3分割し、100名前後の部屋を三つにしてセッションが行われていました。

Untitled

日本だと何日か続くイベントの場合はその都度帰宅するのでずっと会場にいる人は限られてきますがYAPC::NAの参加者は基本的に会場と同じホテルか、隣のホテルなどに泊まっているので三日間ずっと会場にいる人が多いです。私も会場と同じホテルに泊まったので移動はずいぶん楽でした。

DSC_0313

会場と皆さんの宿泊場所が同じせいかもしれませんが、カンファレンスはとてもリラックスした雰囲気でゆったりと進んでいきます。

YAPC::Asia Tokyoの主催者としてカンファレンス会場に来ている人達をみていつも感じてるのは「参加者の皆さんは本当に一生懸命トークを聞きにいくな」ということです。皆さん本当になるたけ多くを吸収しようと頑張っているのだとは思いますが、YAPC::NAでは参加者達は興味のあるトークの時間以外はその辺りで四方山話に花を咲かせていたり、施設内のバーでお酒を飲んでいたり、はたまた部屋で仕事をしていたりとかなりみんな自由に過ごしています。多分一日を通してずっとトークを聞いている参加者は一人としていないのではないでしょうか…?

会場に置いてあったピアノを弾いて待ち時間を過ごす人もいました。ちなみにこの方はジャズピアノを弾いていましたね。

Untitled

とは言え、ホテル内の会場という環境の違いや、このイベントの参加者の人達はそもそも交流をしに来ているという共通認識があるので知らない人に声をかけることも簡単にできるという事もあるので同じような雰囲気を期待するのは無理でしょう。それでも今年のYAPC::Asia Tokyoでもなるたけ交流が生まれるといいなと願っております。

Untitled

関係者に聞いたところこのようなホテルの施設を借りてイベントを執り行うと会期中の飲み物や軽食を合わせた状態で施設利用契約をするそうで、そのおかげで会期中はお菓子、フルーツ、コーヒー、ソフトドリンクは飲み放題、食べ放題でした。さすがアメリカ、という感じですが、イベント主催者としては「う、ここで無理矢理コストを追加されるのか… 辛そう…」と心を痛めずにはいられませんでした…

でもアメリカのレストランで食事をしているとフルーツはなかなか手に入らないので今回フルーツがあったのは個人的にはすごく助かりました!

トークの内容としては今年は比較的Perl6の話題が多かった印象があります。やはり「今年の冬に本リリースをする…かも!」という発表があったからでしょう。ちなみにあまり技術に関係ない禅の心構えみたいなトークも入っていたりして主催者達の試行錯誤がうかがえました。Docker等のコンテナ技術のトークなどもありましたが、その手の「流行り物」トークは比較的おとなしめな印象でした。イベントの性質もあるのでしょうが、ここでもやはり日本人との国民性の差が若干ですが出ている気はしました。

Untitled

また、Perlというと「ああ、あの古いヤツね」というイメージを持たれてしまうのは大変残念なのですが、古いと言うことは今では皆さんが使っている様々なツール類のルーツがPerlにあったりするのです。例えば今ではよく知られているYAMLは以下の写真のIngy氏を含む数名がスペック策定をしています。そういう人達に出会えるのも今回のように自ら海外のカンファレンスに出向いていく醍醐味のうちの一つです。

Untitled

1日目の夜はまず「ミキサー」という名称で、参加者全員が参加できるいわゆる懇親会がありました。ミキサーでは何人かの懐かしい顔を見つけたり、見つけられたり。自分の名前を聞いて「ああ、CPANにあるあのモジュール使ってるよ!」と言われたり、「おい、あの日本でPerlの新しい実装を書いてた二人は今何してるんだ」と詰問されたり(笑)色々と話ができました。

Untitled

Untitled

ミキサーの後は知り合いのツテもあったのでYAPC::NAのスポンサー向けディナーに招待されて混じってきました。ちゃんとした着席ディナー形式でちょっと面くらいましたが、普段だとあまり話さないであろう人達と話せてとても有意義でした。ちなみにこの写真の真ん中に映っている方、僕と同い年くらいかと思ったらまだ4年前に大学を出たばかりだというので多分30前です。向こうも同じ事を思っているとは思いますが「ガイジンの年わからんわー」と思いました。

Untitled

メインディッシュ!アメリカンですねー!うーん、(小声)でもこの肉はあまりおいしくなかった… (見た目もイマイチだったのでフォーカスを敢えて野菜に絞りました)

その晩は最後に近所のバーに行き、行ったところでハッカー達の集まりにありがちな色々な議論がはじまっちゃって、最終的にはプレゼンテーション(もしくな実際のコード)を見せて説明するというおきまり?な流れになってました。写真はMoose等の最初の作者であるStevan Little氏が突然「技術とアート」について語り始めた時のものです。

Untitled

二日目も粛々とカンファレンスは進みます。この日のハイライトは現在のPerl5開発の総指揮をとっているRicardo Signes氏がPerlの作者であるLarry Wall氏に一般公募した様々な質問をぶつけるQ&Aセッションでした。Larryはとにかく不思議なテンポとギャグのセンスがあり、このセッションは彼の人間的な魅力を引き出しつつ様々な彼しかしらないであろう「pack関数はNASAの宇宙計画の中で送られてくるデータの検証を行うために作られた」などのエピソードも含め過去の出来事についての説明等もしてもらえるというかなり興味深いセッションでした。

Untitled

Larryのトークに興味がある方は是非youtubeの動画をどうぞ!ちなみに最初の10分程度はLarryの声が録音できていないようです…

二日目の最後も参加者向けのディナーがありました。ブラジル出身の参加者を見つけて話していたらPerlコミュニティに長らく貢献しているWendyさんと、Perlで開発をしていたら絶対に彼のモジュールのお世話になっているDavid Goldenさんが我々のテーブルに来て一緒にディナーを楽しむ事ができました。

Untitled

ちなみにこのディナーについても主催の端くれとしては心が痛む「300人分用意したのに170人しか来なかった」という辛い話を後で聞きました… カンファレンスの主催って大変なんですよ!<宣伝>「カンファレンス運営の本当の裏側」っていう座談会をやっちゃうくらい大変です!</宣伝>

最終日の三日目、まず自分はその前日にチャリティとして購入を約束していた特製Tシャツを受け取りにいきました。これは主催の一人であるJohn Anderson(genehack)氏が腎臓癌の手術のために参加ができなくなった上手術日がちょうどこの最終日に重なるために応援の一環として有志が作成したものです。最終的にはgenehack氏が彼の選択した慈善団体にお金は寄付するようですが、とにかく応援のためのジェスチャをみんなでしたわけです。

というわけで自分も及ばずながら購入をしたのですが、それはなんと、Larry Wall氏、Perl6の主開発陣の一人であるPatrick Michaud氏、そしてPerl5のRicardo Signes氏三人のサイン入りのシャツでした。帰ったらどこかに保管しておきたいと思います

Untitled

またその後このチャリティTシャツを購入した人達で記念写真を撮りました。

Untitled

この日は自分のトークがあったのであまり聴講はせず、イメージトレーニングをしみたり、スライドの手直しをしたりしていました(16:9で作っていたのに蓋をあけてみたら4:3のモニターだったので慌てて手直しをしました…)。それでも先日知り合った縁でランチに誘ってもらったのでついていきこれまた色々な話をきかせてもらえました。一番右側の人は「シュワルツ変換」で有名なRandal Schwartz氏です

Untitled

その後自分のトークでした。技術的な内容はゼロです。どういうことを重要視しながらいままでYAPC::Asia Tokyoの準備をしてきたか、という話で、基本的にはこれからカンファレンスをやっていきたいと思っている人達向けに自分の経験をシェアしたものです。怖くて自分で録画は見ていませんが、まぁ一応言うことは言えた… と思います。

youtu.be

Twitter上では結構評判がよかったようなので、とりあえず安心という感じです。

その後Lightning Talkや最後のキーノートがあったのですが、この辺りで時差ぼけにより力尽きてしまいまともな記録がなくなってしまいました…

ともあれ、三日間たっぷりと技術に関する交流ができました。またいつか参加できればと思います。実はこの原稿はホテルの部屋で書いているので、これから帰国です。さー、また13時間かけて日本にもどるぞー!

あ、YAPC::Asia Tokyo 2015も是非よろしくお願いいたします

Shibuya English Werewolf Party vol.2

 
こんにちは!Kishi@HDEボドゲ部にぎやかし担当です。

去る2015年5月12日夜に、
第2回目のShibuya English Werewolf Partyが開催されました!

 

f:id:yuki_ks:20150515103548j:plain


台風直撃寸前の悪天候にもかかわらず、
17名の方にご参加いただきました!
ありがとうございました!

普段のボドゲ部は弊社HDEのスタッフ中心のところ、
今回は殆どが外部からのお客様のため、
どうなるのか不安もありましたが、
みなさまのお陰でとても楽しい時間になりました。
  
今回、参加者のCandyさんから
英語の振り返りと人狼以外でも使えるストックフレーズを
勉強できる時間を取ることが出来ました!
これはとても良かったです。
※Candyさんお手伝いありがとうございました:)
 

f:id:yuki_ks:20150515103619j:plain

*1*2*3*4

 
次回もできれば似たようなことができればいいなと思っています。
例えば、議論中言いたくても言えなかった言葉をメモして
ゲーム終了後に英語化する時間をとる、
あわせて、1テーブル7-8名程度にし、
議論時間をゆっくり取り英語で話す機会を増やすなどです。

SEWPは英語を学習することだけが目的ではないのですが、
参加している方のお話を聞いていると、
もう少し各々の英語を見直す時間があってもいいのかな思ってます。

もちろん、ゲームも楽しみたい!

今回も人狼ゲームが初めての方が何人かいらっしゃったので、
人狼ゲームの作戦に対する日本語レクチャーがあったら
もっと英語で人狼ゲームについて話せるし、
聞き取れるしいいかなと思いました。
これはもう少しもんでみます:)

f:id:yuki_ks:20150515111604j:plain


 
テーブルに置かせて頂いているサマリーシートも
バージョンアップ+増刷したいですね!
何かご意見やアイディアがあれば是非お願い致します:)

というわけで、次回は7月開催予定です。
弊社のグローバルインターンシップメンバーが居るタイミングで
開催したいと思います。お楽しみに!!

***以下ゲームレポート***

*1:※下記注訳の英語は、絶賛英語勉強中の筆者コメントです。

必ずしも文法的に正しくない場合があります。

また、品詞・訳の確認はWeblio英和辞典・和英辞典から引用いたしました。

*2:"I vote you"とつい言ってしまう方が多かったので、

誰かに投票するときは"vote for you"が正しいということでした。

vote:【自動詞】投票する【他動詞】票決する

*3:"I'm unbalance."「分からない!」

unbalance:【他動詞】<心の>均衡を破る【名詞】不均衡

いろいろな意見がありすぎて混乱する(=気持ちが不均衡になる)状態を表しています。

人狼意外の場面でも使えそうです。

*4:"One be (un)comfortable in what one's doing. "

uncomfortable:【形容詞】不快な←→comfortable:【形容詞】快適な

これも相手の提案について「いい」「悪い」をストレートにではなくニュアンスで返せる良いフレーズ。

続きを読む

「cloudn (クラウド・エヌ)」を使ってみました

ソリューション推進部 開発&ASPチームの大久保です。

2015/04/17 に開催された社内勉強会にて、NTTコミュニケーションズが提供するパブリッククラウドサービス「cloudn(クラウド・エヌ)」について概要を紹介したところ、AWSが大好きなはず(と勝手に私が思っている)な社内メンバーから、意外やブログで詳しく紹介してほしいというご要望を頂き、ありがたくブログを書かせて頂くことになりました。

cloudn とは?

お決まりの書き出しですみません。URLだけ紹介させてください。

www.ntt.com

使ってみる

cloudn が提供する 仮想サーバ(Compute)を使ってみました。仮想サーバには、FLATタイプ、VPCタイプ OpenNW, VPCタイプ ClosedNW の3タイプが提供されています。AWSと機能比較すると、FLATタイプ = EC2-Classic, VPCタイプ = EC2-VPC となります。今回は、FLATタイプの仮想サーバを管理コンソールとAPIを使って作成してみます。

仮想サーバを作成する

管理コンソールの操作方法についてはマニュアルに大変わかりやすく書いてありますのでこちらをご覧ください。ここでのポイントはブラウザに Firefox を使用することです。IEやChromeだと管理コンソールが正常に動作しないことがあります。ウィザードでの設定が終了してから、仮想サーバが起動するまでは 30秒~1分程度です。

3.1. 仮想サーバーを作成する — Cloudn Compute FLATタイプ 操作マニュアル v2.20.2

仮想サーバを設定する

今回、オフィシャルテンプレートの CentOS 6.5 64bit から仮想サーバを作成しました。開発やサービスで複数台の仮想サーバを作成する場合、OSの基本設定などはあらかじめ済ませた状態のテンプレートがあると便利なので、まずはテンプレートの元になる仮想サーバの設定を行います。

タイムゾーン・言語

cloudn の仮想サーバはデフォルトでは、タイムゾーンが UTC になっています。/root/tzconfigurator.sh というシェルスクリプトが用意されており、対話形式でタイムゾーンの設定が行えます。が、私はいつものやり方でささっと設定します。

タイムゾーンの設定

# cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
# cat /etc/sysconfig/clock
ZONE="Asia/Tokyo"

言語の設定

# cat /etc/sysconfig/i18n
LANG="en_US.UTF-8" -> 日本語にしたい場合、ja_JP.utf8 に変更
SYSFONT="latarcyrheb-sun16"


ネットワーク

ホスト名、iptables などささっと設定します。セキュリティグループの設定が必須なので不正アクセスされるリスクは低いですが、デフォルトだと iptables は全開放、かつ、chkconfig off という状態で起動します。かなり豪快です。

ホスト名

# cat /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=no (IPv6無効)
HOSTNAME=template.localhost.localdomain (ホストFQDNを設定)

iptables

# cat setting-iptables.sh
iptables -F
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p icmp -j ACCEPT
iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -s 接続元IP/32 -p tcp -m tcp --dport 22 -j ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# sh setting-iptables.sh

# service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[  OK  ]

# chkconfig iptables on
# chkconfig --list | grep iptables
iptables        0:off   1:off   2:on    3:on    4:on    5:on    6:off


時刻同期(NTP)

仮想サーバはOS停止していると時間が止まりますので、NTPを使用してサーバの時刻をあわせます。cloudn FLATタイプは 直接インターネットに接続されているので、CentOS 標準の /etc/ntp.conf でタイムサーバと通信できます。国内のタイムサーバですと、 MFEEDなどが利用できます。ntpd もデフォルトで起動しているので、タイムサーバがデフォルト設定でよければ、NTPを動作させるための設定は特にありません。

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-secure.opticner 223.255.185.2    2 u   15   64  377   13.196    9.558   6.019
*v157-7-235-92.z 10.84.87.146     2 u   24   64  377   15.089  -14.547   3.478
+c-kint.tv       133.243.238.243  2 u   17   64  377   13.842   -9.597   4.046
+x.ns.gin.ntt.ne 103.1.106.69     2 u   11   64  377   12.129  -13.728   3.157


DNS

DNSサーバは cloudn から提供されており、/etc/resolv.conf に設定されています。そのまま利用できます。


ユーザ・グループ

サーバへのアクセスポリシーは様々あるかと思いますが、私は root への昇格が可能なシステム管理ユーザを作成し、SSH では、root ログイン禁止にしています。ユーザを作成したら SSHキーも登録しておきましょう。以下、/etc/ssh/sshd_config の設定例です。

# diff sshd_config sshd_config.org
42c42
< PermitRootLogin no (rootユーザのログイン禁止)
---
> #PermitRootLogin yes
47,49c47,49
< RSAAuthentication yes (RSA公開鍵認証を有効化)
< PubkeyAuthentication yes
< AuthorizedKeysFile    .ssh/authorized_keys
---
> #RSAAuthentication yes
> #PubkeyAuthentication yes
> #AuthorizedKeysFile   .ssh/authorized_keys
66c66
< PasswordAuthentication no (パスワードログインを無効化)
---
> PasswordAuthentication yes
139,140d138
<
< AllowUsers hoge fuga (SSHログイン可能なユーザを限定)


ディスク

cloudn はルートディスクに 15GB の容量を割り当ててくれます。AWSではスワップ領域が確保されておらず、必要であればEBSにスワップファイルを作成する必要がありますが、cloudn はデフォルトで 2GB のスワップ領域が確保されています。以下、vQプランのディスクとメモリの割り当て状況です。

# df -h
Filesystem                    Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root   13G  755M   11G   7% /
tmpfs                         246M     0  246M   0% /dev/shm
/dev/vda1                     485M   33M  427M   8% /boot

# free -m
             total       used       free     shared    buffers     cached
Mem:           490        122        367          0          6         38
-/+ buffers/cache:         77        413
Swap:         2047          0       2047

テンプレートを作成する

その他監視エージェントやら必要なパッケージやらインストールしてOS設定が完了したらテンプレートを作成します。またしてもマニュアル参照ですみません。マニュアル通りにテンプレートを作成します。

3.15. テンプレートを作成する — Cloudn Compute FLATタイプ 操作マニュアル v2.20.2

テンプレートをコピーする

cloudn をサービスで使用する場合、冗長化のために異なるゾーンにAP, DBサーバを配置します。一方で、テンプレートはゾーンごとに有効です。(ゾーン jp-e1a で作成したテンプレートを使用して、ゾーン jp-e1b に仮想サーバを作成することはできません)ですので、作成したテンプレートは各ゾーンにコピーする必要があります。

8.3. テンプレートをコピーする — Cloudn Compute FLATタイプ 操作マニュアル v2.20.2

APIを使う準備をする

cloudn は オープンソースのクラウド基盤 Apache CloudStack をベースとしたサービスであるため、APIの操作に cloudmonkey CLIを使用することができます。マニュアルにも書いてあります。マニュアルに従って cloudmonkey をインストールし、URL, apikey, secretkey を設定します。apikey, secretkey は、管理コンソールにログインした直後のページの下の方に「portal contents」>「APIアクセスキー秘密鍵管理」というメニューがあります。これをクリックすると取得できます。

1.3. APIクライアントの利用 — Cloudn Compute FLATタイプ APIリファレンス v2.20.2

今回は仮想サーバの作成/起動/停止/削除、アプリケーションのプロビジョニング、SSHログインなど何かと便利な Vagrant と cloudmonkey を組み合わせて使用します。Vagrant はこのあたりを読んでインストールしてください。

cloudmonkey と vagrant がインストールできたら、vagrant-cloudstack プラグインをインストールします(これで合体します)。

$ vagrant plugin install vagrant-cloudstack
Installing the 'vagrant-cloudstack' plugin. This can take a few minutes...
Installed the plugin 'vagrant-cloudstack (1.0.0)'!

いよいよ仮想サーバの量産体制が整いました。APIを使って仮想サーバを作成するためには以下のパラメータが必要です。

セキュリティグループID

管理コンソールの「ネットワーク」>ビューの選択「セキュリティグループ」>一覧から仮想サーバに適用するセキュリティグループをクリック>「詳細タブ」にIDが記載されています。これをメモ。

テンプレートID

管理コンソールの「テンプレート」>テンプレート名をクリック>「詳細タブ」にID(テンプレートID)が記載されています。これをメモ。

ゾーンID

cloudmonkey CLI を使って取得できます。

$ cloudmonkey list zones
count = 2
zone:
name = jp-e1a
id = 1b02e74c-6c21-4aa3-b96c-51042de8fccd
:

インスタンスタイプID

同じく cloudmonkey CLI を使って取得します。

$ cloudmonkey list serviceofferings
count = 7
serviceoffering:
name = t1.micro
id = 200c6378-8ae9-4718-9b25-b8c4f6c1dfc8
:

これで、「どのテンプレートを使って」、「どのセキュリティグループを適用して」、「どこ(ゾーン)に」、「何の(インスタンスタイプ)」仮想サーバを作るかを指定できます。

APIを使って仮想サーバを作成する

上記のパラメータがあれば、Vagrant を使ってさくっと仮想サーバが作成できます。今回ご紹介している Vagrantfile は、仮想サーバを作成し、Vagrantを実行したサーバと作成した仮想サーバ間でディスクを共有することでアプリケーションに必要なファイルを転送し、vagrant/init/setup.sh をプロビジョニング時にキックすることにより、アプリケーションのインストール・設定まで実行しているテンプレートです。小中規模のシステムであれば、ChefやPuppetなどのプロビジョニングツールを使わなくても自動化できるかと思います。Vagrantは環境変数を読んでくれるのでパラメータは環境変数に定義しています。

作業ディレクトリを作成
$ mkdir vagrant
$ cd vagrant

Vagrantを初期化
$ vagrant init

Vagrantfile を以下の通り作成する。
$ cat Vagrantfile
# -*- mode: ruby -*-
# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

  # Every Vagrant virtual environment requires a box to build off of.
  config.vm.box = "dummy"
  config.ssh.private_key_path = "~/.ssh/id_rsa"
  config.ssh.username = "cmcadmin"
  config.vm.synced_folder ".", "/vagrant", disabled: true
  config.vm.synced_folder "provision/", "/home/***/vagrant"
  config.vm.synced_folder "conf/", "/home/***/vagrant/conf"

  config.vm.provider :cloudstack do |cloudstack, override|
    cloudstack.host = "comp-api.jp-e1.cloudn-service.com"
    cloudstack.path = "/client/api"
    cloudstack.port = "443"
    cloudstack.scheme = "https"
    cloudstack.api_key = "${APIKEY}" -> cloudn のアクセスキー
    cloudstack.secret_key = "${SECRET}" -> clooudn の秘密鍵
    cloudstack.instance_ready_timeout = 1800

    cloudstack.display_name = "${VM_HOSTNAME}" -> 仮想サーバの表示名(管理コンソール上に表示される)
    cloudstack.name = "${VM_NAME}" -> 仮想サーバの名前(管理コンソール上に表示される)
    cloudstack.group = "${VM_GROUP}" -> 仮想サーバのグループ(管理コンソール上に表示される)

    cloudstack.template_id = "${CLOUDN_JPE1A_TEMPLATE_ID}" -> テンプレート
    cloudstack.service_offering_id = "${CLOUDN_SERVICE_OFFERING_ID}" -> インスタンスタイプ
    cloudstack.zone_id = "${CLOUDN_JPE1A_ZONE_ID}" -> ゾーン
    cloudstack.security_group_ids = ["${CLOUDN_SECURITY_GROUP_ID}"] -> セキュリティグループ
    cloudstack.network_type = "Basic"
  end
  config.vm.provision :shell do |shell|
        shell.privileged = false
    shell.inline = "vagrant/init/setup.sh"
  end

end

仮想サーバを作成・起動する
$ vagrant up

vagrant up してからサーバが起動するまでは調子がいいと5分程度でです。アプリケーションの インストールなどを除くと、1~2分程度で仮想サーバの作成と起動が出来ているように思います。

終わりに

今回は仮想サーバの作成方法を中心にレポートしましたが、データディスクのアタッチや、DNSへの正引き・逆引きレコード登録などもAPIでできますし、VPCタイプでは、セキュアな3層モデルのウェブアプリケーションを構築することも可能です。コスト競争力もありますし、「cloudn(クラウド・エヌ)」 なかなか良いサービスではないかなと思います。

Pythonでvirtualenvの構築を自動化する

おはこんばちは!! 尾藤 a.k.a. BTOです。

pythonで開発環境を構築する時は、virtualenvを使うことが多いかと思います。 弊社のプロダクトでもvirtualenvを使って、各開発者の環境を統一しています。

そこで問題になるのがvirtualenvの構築です。 virtualenvの構築を主導でやっていると、手作業によるミスが起きやすいですし、何より最初からすることが決まっている処理は自動化したいものです。

そこで、virtualenvの環境を自動で構築するために、virtualenvのbootstrapを使用しています。

virtualenv bootstrap script を作っておけば、

% python create.py ~/.venv/your-project

みたいにして、コマンド一発でvirtualenvの構築と必要なライブラリのインストールが一発でできるようになり、各開発者の環境統一が簡単にできるようになります。

virtualenv bootstrap

virtualenvにはbootstrapという機能がついています。 bootstrapを使うと、virtualenvの構築任意の事後処理を1発で実行するbootstrap scriptを生成してくれます。 プロジェクトでbootstrap scriptを作っておけば、コマンドを1発実行するだけで、同じライブラリ、バージョンを持ったvirtualenvを構築できます。

bootstrap scriptの生成

では、どのようにしてbootstrap scriptを生成すればいいのでしょうか。 virtualenvにはbootstrap scriptを生成する機能がついています。

virtualenv.create_bootstrap_script() を呼び出すと、bootstrap script用の文字列を返してくれますので、あとはそれをbootstrap script fileに書き出すだけです。 virtualenv.create_bootstrap_script() には事後処理を実装するスクリプトの文字列を渡すことができます。

#!/usr/bin/env python

import os
import virtualenv

extra_script = open('extra.py').read()
script = virtualenv.create_bootstrap_script(extra_script)
f = open('create.py', 'w')
f.write(script)
f.close()

freeze.py

これはvirtualenv bootstrap scriptを生成するfreeze.pyです。 ここではextra.pyから事後処理のスクリプトを読み込み、create.pyというvirtualenv bootstrap scriptを生成しています。

import os

def after_install(options, home_dir):
    pip = os.path.join(home_dir, 'bin', 'pip')
    os.system(pip + ' install Fabric')
    os.system(pip + ' install boto')
    os.system(pip + ' install pep8')
    os.system(pip + ' install tornado')

extra.py

extra.pyはこんな感じでafter_installにvirtualenvインストール後の処理を書きます。 ここで必要なライブラリをインストールするようにすれば、virtualenvの構築とライブラリのインストールが一発でできるようになります。

これで準備が整ったので、freeze.pyを実行すると、create.pyを生成してくれます。

% python freeze.py

できたcreate.pyをリポジトリにコミットすれば、他の開発者にも同様な環境を簡単に構築できます。

requirements.txtを使う

pythonのプロジェクトではrequirements.txtというファイルがよく使われます。 これはただのpip freezeの出力結果なのですが、そのプロジェウトで必要なライブラリやバージョンを簡潔に表現することができます。

requirements.txtの生成は簡単です。 pip freeze の結果をファイルに書き出しましょう。

% pip freeze > requirements.txt

それでは先ほどのvirtualenv bootstrap scriptでrequirements.txtを使うようにしてみましょう。 それにはextra.pyでpip installしている部分をrequirements.txt経由でインストールするように変更するだけでできます。

import os

def after_install(options, home_dir):
    pip = os.path.join(home_dir, 'bin', 'pip')
    os.system(pip + ' install -r requirements.txt')

extra.py

これで、今後はrequirements.txtを更新するだけでよくなりました。

wheelを使う

ここまでで、環境構築の自動化がかなり進みました。 しかし、現状ではpipでライブラリのインストールを最初から行うため時間がかかってしまいます。 毎回pipサーバに取りに行くのも無駄です。 コンパイル済みのパッケージがローカルにあれば問題は一気に解決します。 そのためにwheelというものを使います。

wheelはpythonのパッケージを配布するためのフォーマットです。 wheelのパッケージはコンパイル済みのため、インストールが高速にできます。 事前にwheelパッケージを作ってローカルに持っておけば、pipサーバにアクセスせずに高速にインストールすることができるようになります。

wheelパッケージを作るのは簡単で、次のようにコマンドを実行するだけです。

% pip wheel -r requirements.txt

コマンドを実行すると、wheelhouseというディレクトリにwheelパッケージが作られます。 拡張子は.whlです。

では今度はwheelパッケージを使ってインストールするようにしてみましょう。 after_installのところで、wheelパッケージを使ってインストールするように変更するだけです。

import os

def after_install(options, home_dir):
    pip = os.path.join(home_dir, 'bin', 'pip')
    os.system(pip + ' install --use-wheel --no-index --find-links=wheelhouse')

extra.py

これでpipサーバにアクセスする必要もなくなり、インストールも高速にできるようになりました。

結論

HDEでは英語で人狼を開催します。 ご興味のある方はご連絡ください。

Shibuya English Werewolf Party vol.2 | Facebook