HDE BLOG

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

SORACOM Air/Beamはどんな問題を解決するのか、IoT素人の目線で考えてみる

こんにちは。HDEの小椋です。SORACOM リリース記念リレーブログ に参加させていただいております。

僕は機械・電気系はまったくの音痴、IoTも素人です。でも、クラウドは一応素人ではないので、オンプレミス機器をどんどんクラウドに移行したように、物理的な機器もどんどんクラウドのパワーを活用して、現実世界を豊かにすることができるんじゃないか、ということをよく妄想します。しかし、その時にいつも壁として立ちはだかるのが、物理セキュリティの問題です。

SORACOM Air/Beamが、それらの問題をエレガントに解決してくれたことに、とても興奮しています。うまく説明できるかどうかわからないのですが、以下チャレンジしてみます。

たとえば、家の玄関のチャイムを、クラウドとRaspberry Piのような安価な機器で実現することを考えてみましょう。面倒くさいので、とりあえず通話機能とかその他の機能とかはのぞいて、チャイム機能だけ考えることにします。

要件:玄関に来た人がボタンを押したときに、スマホに通知したい

という単純な問題を考えてみます。

f:id:goura:20151006023827p:plain

ボタンの部分はRaspberry PiとかEdisonとかにして、家の無線LAN経由でクラウドに接続し、クラウド側の何かのAPIを呼び出して、スマホに通知を送る。こうすれば、Raspberry Pi以外に特別な機器も要らないし、良さそうですよね。クラウドが得意な人なら、ちょっと電子工作するだけでできちゃいそうなので、一瞬ワクワクします。

でも、よく考えるとそう簡単でも無いんです。この時、Raspberry Pi側には、少なくとも二つの大事な情報が格納されています。一つは無線LANの認証情報、もう一つはクラウドのAPIの認証情報です。もしRaspberry Piだったら、実機を盗まれたら簡単に読み取れてしまう情報ですよね。

もし悪意を持った人が、玄関先にあるRaspberry Piを盗んだらどうなるか。無線LANの認証情報は、もし盗まれたら家の無線LANにタダ乗りされてしまったり、家のLANに侵入されてしまうかもしれない大事な情報です。クラウドのAPIの認証情報のほうは、万が一盗まれたら、いつでもどこでもピンポンが鳴らせる、無制限完全ピンポンダッシュが成立してしまいます。

  • 無線LANの認証情報は、家で普段使っている無線LANと別の無線LANにしておけばいいじゃないか
  • クラウドのAPIは、盗まれたことがわかった時点で認証情報を無効化すればいいじゃないか

と思うかもしれませんが、家で普段使っている無線LANと別の情報にしたとしても、タダ乗りは防げません。また、認証情報の無効化については、盗まれたことが検知できるならばそれでもどうにかなるかもしれませんが、検知に失敗し、盗まれたことに気づかないとどうしようもありません。たとえば、物理的にRaspberry Piを盗むのではなくて、盗んで素早くSDカードの中身をコピーして、また元に戻したらとしたらどうでしょうか。情報が盗まれたこと自体に気づかないかもしれません。

ちょっと考えただけでも「安心できる状況」を作るのは結構面倒くさいということがわかります。

SORACOM Air/Beamを使えば、こうした問題を解消できる可能性があります。

SORACOM Beamは、「SIM単位の認証と通信経路の保護をSORACOMが代わりに引き受ける」機能だと表現することができます。SORACOM Beamを使うと、SIMそのもの以外、Raspberry Pi側にはなにも認証情報を置かずに、そのSIM経由での通信が来た時のみ、SORACOMが代理で、あらかじめ登録してある認証情報を付加して第三者のクラウドAPIを呼び出すようなことが可能になります。クラウドAPIを呼び出すにあたっては、IMSIと呼ばれるSIMの識別番号の情報も付加することができます。

つまり、Raspberry Piは、SORACOMのSIM、SORACOM Airを使って通信さえすれば、無線LANの接続情報も、クラウドのAPIキーも、Raspberry Piには置かなくていいのです。証明書ストアの更新とか、そうしたことも忘れていい。大事な情報は全部、第三者に手の届かないクラウド側に置くことができます。

いわゆる「クローン携帯」が存在していないことを鑑みても、SIMを複製したりすることは相当に難しそうなので、SORACOM Beamは、問題をだいぶ単純化してくれる現実的な解であることがわかると思います。

上では触れませんでしたが、「100台置きたかったらどうするか問題」もあります。100台それぞれに別々の認証情報を設定することを考えると面倒ですし、一方全部同じ認証情報を設定してしまうと、万が一盗まれたときの被害が大きくなりますし、機器の入れ替え等で、数台だけアクセスを取り消したい、というような状況も面倒臭そうです。SORACOM Air/Beamを活用すれば、認証情報を各機器に格納する必要が無いため、100台全部に同じソフトウェアをデプロイした上で、どの機器にどのSIMカードを刺したかだけを記録しておけば良く、アクセス許可や、認証情報についてはクラウド側で集中管理することができます。

チャイム程度なら、他の無線テクノロジーでどうにかできるかもしれませんが、例えばドローンとか、デジタルサイネージとか、ロボットとか、クラウドから機器をコントロールするものの応用範囲は無限にありそうです。可能性が一気に拡がった感じで、ワクワクしませんか。そもそも3Gモジュールの値段がまだ高すぎたり、まだSORACOMが日本でしかサービスしていなかったり、まだまだ解決すべき課題はたくさんありますが、少なくとも大きな前進であることは間違いないですよね。

少し前に、うちの会社のインターン生がRaspberry Piで作った、クラウドベースのデジタルサイネージの社内導入を検討した際、上記のような話が問題になり「金属製のケースを作って南京錠でロックしてはどうか」などと議論した挙句面倒くさくなって話が立ち消えになるのを経験した私としては、例えば一般企業で、社内で実験的にIoT機器を導入したりするにあたっては、リスク受容できるところまでだいぶハードルが下がったのではないかと感じました。

さて、僕の文章は必要以上に長く、退屈なことで有名です。ここまで読んでいただき、ありがとうございました。ここで終わりと言いたいところなのですが、せっかくなので上記の話を実感するために、玄関チャイム的なものを試しに作ってから終わりたいと思います。

実際に作ってみる

用意するもの

  • Slack
  • SORACOMのSIMで通信可能な、Raspbian jessieが入ったRaspberry Pi
  • プッシュスイッチ、ブレッドボード、ジャンパ線

「SORACOMのSIMで通信可能なRaspberry Pi」が現在若干ハードル高めですが、このリレーブログシリーズが終わるころには、きっといろんな選択肢が説明されていることと思います。僕は @j3tm0t0 さんの

を参考にFS01BU(SORACOM自身が販売している)を使いました。

難しければ、とりあえず今回はあくまでもproof of conceptですので、SORACOM Airを刺したWiFiルーターとかスマホ(への無線LAN経由でのテザリング)とかの普通の接続で代用して、あとは心の中でPPP接続をしましょう。とにかくRaspberry PiがインターネットにアクセスするときにSORACOM Air経由で行くようにすれば以下の実験は可能です。

通知には、一番簡単なSlackを使います。Raspberry Piにつながったボタンを押すとSlackに通知が飛ぶようにしてみましょう。スマホにSlackのアプリを入れておけば、スマホ宛に通知を送ることもできますよね。

f:id:goura:20151006150145p:plain

こんな感じで、Raspberry PiはSORACOM Beamに対し、SORACOMの内部ネットワークを通じてHTTPでリクエストを送り、それを受けたSORACOM Beamが(特定のグループに入っているSIMからの通信の場合に限り)Raspberry Piの代わりに認証情報(APIトークン)を付加して、インターネット経由でHTTPSでSlackにAPIリクエストを送ります。

Raspberry Pi側には、SIMカード以外の認証情報は置きません。

今回は、SlackのWeb APIのうち、「chat.postMessage」 を使います。

このAPI呼び出しに必須となる引数は

  • token
    • 認証情報
  • channel
    • 宛先
  • text
    • メッセージの内容

の三つです。今回の試みでは、メッセージの内容はRaspberry Piから送り、SORACOM Beamで認証情報と宛先を付加します。

Slack Web APIの引数は "can be passed as GET or POST params, or a mix" という仕様なので、今回は行儀悪くmixする方向で行きます。

Raspberry PiはPOST paramでtextを送信し、そのリクエストに対し、SORACOM BeamがGET paramsとしてtokenchannelを追加します。

Beam側の設定を変えれば、Raspberry Piに変更を加えずに宛先や投稿するSlackのチームを変えることも可能な例を考えてみました。

SlackのAPIトークンの取得

https://api.slack.com/web の下の方に、簡易的な、全権を持ったトークンを発行するボタンがあります。今回はこれで試してみましょう。

f:id:goura:20151006031443p:plain

ボタンを押すと、上の図のボタンの左「none」と書いてあるところにAPIトークンが入りますので、控えておきましょう。

SORACOM Beamの設定

Beamの設定はユーザーコンソール「グループ」から行います。適当なグループを作った後、そのグループの「SORACOM Beam設定」から「HTTPエントリポイント」を追加します。

f:id:goura:20151006031602p:plain

「エントリポイント」のパスに/を、「転送先」のホスト名に「slack.com」を入れます。「転送先」のパスには、

/api/chat.postMessage?token=<<APIトークン>>&channel=@kazuhiro

を登録します。 <<APIトークン>> は上記で発行したAPIトークン、@kazuhiroのところは自分のSlackの@IDに置き換えてください。(画像では途中で切れていますのでご注意ください。&channel=@kazuhiroを忘れずに)

f:id:goura:20151006113048p:plain

このグループに、Raspberry PiからアクセスするSIMを登録します。SIM管理画面からSIMを選んで「詳細」です。

f:id:goura:20151006113858p:plain

この状態で、このグループに登録されているSIMが刺してあるRaspberry Piから http://soracom.io:8888/ にHTTP POSTすると、SORACOM Beamが https://slack.com/api/chat.postMessage?token=<<APIトークン>>&channel=@kazuhiro に同じ内容をPOSTしてくれるはずです。

Raspberry Pi上のcurlから、試しにリクエストを投げてみましょう。

設定が間違っていなければ、

$ curl -X POST -d 'text=hello' http://beam.soracom.io:8888/
{"ok":true,"channel":"D0BSL33EX","ts":"1444063662.167012","message":{"text":"hello","username":"bot","type":"message","subtype":"bot_message","ts":"1444063662.167012"}}

のような応答が帰ってきて、slackbotから "hello" という内容のDMが届くはずです。 (僕の環境だと、スマホにプッシュ通知が来るのは30秒後ぐらいだったので、玄関チャイムとしてはちょっと実用性に難あり)

プッシュスイッチの結線

ここまでできれば、後は押しボタンを付けるだけです。……とはいえ僕は電気はまったくの素人です。 押しボタンの結線、押しボタンを押したことの検知は、以下の記事を参考にしました。

O'Reilly Raspberry Pi Cookbook http://razzpisampler.oreilly.com/ch07.html

記事を参考に、GPIO 18番とGNDにプッシュスイッチをつなぎます。

Raspberry Pi 2の場合は、ピン配置が少し違いますので注意しましょう。

www.raspberry-pi-geek.com

そして、以下のPythonプログラムをどうにかして、Raspberry Pi上にswitch.py として保存します。

短縮URL作りました。curl -L https://goo.gl/4ijyJi > switch.py等で取得できます)

で、そのswitch.py を、同じくRaspberry Pi上で

$ sudo python switch.py

として起動すると、ボタンを押すたびに画面に

button pressed
text=hello%21

のような文字が表示されて、SlackにDMが届くはずです。

ということで、完成!

f:id:goura:20151006032159j:plain

Lチカから先に進んだことが無かったド文系の僕でもIoTできました。感動です。

Raspberry Piは、単に http://beam.soracom.io:8888/ にアクセスしているだけで、何の認証情報も設定していません。仮にこれをプロダクトにして100台、それぞれ全く違う家庭に販売することになったとしても、SDカードの中身は全部同じでいいはずです。SIMの所属するグループが異なれば、異なるSORACOM Beam設定が適用可能なので、機器毎に違うSlackに投稿させることもできます。SORACOM Beam、便利ですね。

後片付け

遊び終わったら、ここで使ったAPIトークンは忘れずに無効化しておきましょう https://api.slack.com/web の右上の "My Auths" をクリックした後の画面のゴミ箱マークから無効化が可能です。 f:id:goura:20151006114711p:plain f:id:goura:20151006114724p:plain

まとめ

図をノートPCのトラックパッドだけで描こうとするのは無謀

YAPC::Asia Tokyo 2015に参加しました

こんにちは、クラウドプロダクト開発部の篠原です。

20-22日にYAPC::Asia Tokyo 2015が開催されました。同僚に主催者の牧さんがいたり弊社もスポンサードしていたりという縁もあり、初めてYAPCに参加してきました。 (HDEがスポンサードするようになった経緯はこちら: HDE Inc x YAPC::Asia Tokyo 2015 - HDE BLOG

YAPCの興奮が冷めないまま週が明け出社したところ、突然向かいの席にいる牧さんから

と言われてしまったため、わたしもブログを書くことにしました。

Perl Conference?

YAPCは「Yet Another Perl Conference」の略で、Perlのカンファレンス…ではありません。 YAPCでは、Perlに限らずGolangやJavaScriptなどPerl以外のプログラミング言語のトークからリモートワークやエンジニアとしての姿勢など働き方のトークまで、多種多様なトークが発表されました。わたしは普段はJavaScriptやGolangを使っているので、YAPCは今までPerlのカンファレンスと思ってスルーしていました。完全に騙されました。

Comment about Talks

YAPCのトーク一覧とスライドは、公式ページのTalksで確認できます。感想などは、公式ページの感想エントリまとめや、Togetterで確認できます。ためになるトークばかりだったので、ぜひご覧ください!折角なので、個人的に印象に残ったトークをさくっとご紹介します。

我々にできるOSSとそのコミュニティの育てかた - @tagomoris

www.slideshare.net

Treasure Dataの@tagomorisさんの発表です。OSSを公開する理由からOSSをどうやって育てていくかとい発表でした。弊社も過去にOSSを公開して苦労したので、発表の間は頻繁に共感していました。発表の中で印象的だったのが「IssueやPullRequestは常に英語を使う。日本語のPullRequestは即却下」といった英語の重要性です。弊社は会社の共通言語として英語を採用予定で、現在進行形で英語に激しく苦労しているため、激しく同意せざるを得ませんでした。

Effective ES6 - @teppeis

www.slideshare.net

Cybozuの@teppeisさんの発表です。先々月仕様が公開されたECMAScript6についての発表でした。わたしは普段フロントエンドエンジニア的な仕事をすることが多いので興味津々でした。内容は、ES6の仕様をかいつまんだわかりやすい説明でした。ES6の仕様は、Pythonなど他の言語と似た仕様が多く、使いやすそうで学習コストも少なそうという印象を持ちました。これからはES6の時代ですね。また、ES6からES5のコードを生成するTranspilerであるBabelを紹介されていました。「これからはバベっていこう」がキーワードでした。バベっていきましょう。

YAPC::Asia Tokyo 2016?

以上ですが、簡単なトークの紹介でした。

とてもためになったので来年もYAPCに参加するぞ!と意気込んでいたのですが、なんとYAPC::Asiaは今年で最後らしいです。まさか初参加で最後とは…。YAPCのように垣根のない多種多様なカンファレンスは貴重なのでかなり名残惜しいです。が、つぎはPerlという冠がないカンファレンスが開催されるとかされないとかいう噂が!?楽しみです!

最後になりましたが、YAPCの運営スタッフの皆様、お疲れ様でした!

GopherCon 2015に参加してきました

クラウドプロダクト開発部たなべです。

去る2015年7月にアメリカはコロラド州デンバーで開催されたGopherCon 2015に参加してきました。 アメリカ出張は昨年のDockerConに続いて2度目です。

デンバーはみんな大好きサンフランシスコから約1900km離れています。Google Mapによれば車で18時間だそうです。飛行機なら2時間ですので西海岸からのアクセスも良好と言えそうです。昨年からは成田空港、デンバー国際空港間で直行便の運行が始まり便利になったそうです。

今回はエクストリーム和装家としても有名なCTOと一緒に行きました。

上の記事でも触れられていますが、滞在期間中のデンバーはあまりパっとしない天気で、どちらかといえば日中もすこし肌寒い気温でした。

f:id:nabekent:20150803142655j:plain

GopherCon二日目は晴れ間が見えましたが、滞在中は雨が降ったり止んだりと不安定な天候でした。

会場となったのは上の地図で上げたコロラドコンベンションセンターです。コロラド州といえばロッキー山脈などの大自然です。

f:id:nabekent:20150803141052j:plain (熊もGopherConに興味津々の図)

f:id:nabekent:20150803142008j:plain 会場前にはCoreOSトラック(バス?キャンピングガー的なもの?)が止っていました。ひょっとしてCoreOSチームはこれに乗って1900kmもはるばる来たんでしょうか…?

f:id:nabekent:20150803141347j:plain

まずGopherConで驚いたのは参加者に配られるグッズの豪華さでした。

f:id:nabekent:20150803141550j:plain

ただのリュックではありません。参加者がほぼ開発者であることを見越して、きちんとラップトップ収納用スペースがあり、バッテリーやケーブルなどの細かいものもきちんと入れられるものでした。

f:id:nabekent:20150803235202j:plain

ロゴ入りのコップです。アメリカンな大きさですが、この季節、麦茶をめいっぱい入れて飲むのに使っています。お気に入りです。

他にもスポンサー提供のグッズがリュックに大量に入っていました。

GopherCon 2015のメインセッションはシングルトラックで二日間で計22セッションが行なわれました。そのためセッションは朝から夕方までびっしり入っています。

f:id:nabekent:20150803143230j:plain

朝7時すぎから朝食が用意されました。

f:id:nabekent:20150803143634j:plain

コーヒー、甘いもの、そしてオートミール。メニューは両日とも同じでした。

f:id:nabekent:20150803143756j:plain

Wikipediaを読むと健康食として人気のようです。ただ、見た目がアレでCTO曰く、日本人でちゃんと食べたのは私が初めてとのことです。シュガーやドライフルーツを入れればおいしく食べられました。

13時から昼食でしたが、ビュッフェスタイルにも関わらずパイプラインが4本程度しかなくスループットがまったく出ていませんでした。そのため会場の外に人が溢れ返っていました(Goのカンファレンスなのに!!)。そしてお昼の写真は取り忘れました…。

朝食と昼食は見知らぬ人との絶好の会話の機会です。どういう仕事をしているのか、どういう技術スタックを使っているのか、どこで苦労しているのかなどを情報交換できるのがカンファレンスのもう1つの目的です。今回は英語が話せるCTOもいたため興味深いGoのユースケースを聞くことができました(そして大抵そういう話は書けない)。

f:id:nabekent:20150803155647j:plain

ホール外にはスポンサーブースがありました。今回はCoreOSのetcd Tシャツをゲットしました。

f:id:nabekent:20150803155806j:plain

いくつかのセッションについて触れたいと思います。すべてのセッションのスライドと動画は http://blog.golang.org/gophercon2015 から辿れます。

動画では省略されていますが、MCはCoreOSのKelsey Hightower氏でした。

ベテラン司会者を彷彿とさせる軽快なトークとジョーク(みんな笑ってるけど英語がまったく聞き取れず笑えなかった)で笑いを量産していました。いよいよ今月となったYAPC Asiaでのトークがとても楽しみです(同時翻訳付き!!)。

Go teamからはオープンソースコミュニティとしてGoについてのトークがキーノートそしてクロージングで行なわれました。

Goはもともと数名の少数チームで言語デザインを行なってきました。初期にはこれらはうまく行きましたが、Goのエコシステムが拡大するにつれコミュニティと協力してこれらのGoを作っていくことが重要という趣旨をGo teamが繰り返し話していたのが印象的でした。

  • vendoringについて: 従来Googleでは問題ではなかったとの姿勢だったのが『Goコミュニティは「問題」として認識していること』を認識し、Do Less, Enable Moreに基いてGo 1.5に実験的機能(GO15VENDOREXPERIMENT)を入れ、よりよいベンダリングのための仕組みを設計していく
  • Code Of Conductついて: コミュニティを形成していくにあたりCode Of Conductの必要性があるのではないかという発議
  • デザインプロセスの明文化: 提案の仕方、提案の評価、提案の履歴などを残せるように仕組みを用意していく

次の5年(10周年)に向けての足固め的セッションだと感じました。私も影ながら見守っていきたいです。

そして、英語

こうして海外のカンファレンスに行けるのはこのブログでも何度も触れているように英語の社内公用語化を来年に控えているためです(つい最近コピー機の言語設定が英語になりました)。

CTOは帰国子女で私から見ればペラペラです。しかしそれでもセッション後の質疑応答の聞き取りには苦労したそうです。無論、私はまったく聞き取れませんでした。

日本国内にいてそれなりに日本人の話す英語、アジア人が話す英語が聞き取れるようになった私ですが、やはりネイティブが話す英語を聞き取るにはまだまだ訓練が必要(そして私にとっての今の壁)であることを再認識したアメリカ出張でした。

ともあれ、言語習得に近道はなさそうですから、来年はもうちょっと成長して海外出張に行けるようまた1年がんばりたいと思います!!

f:id:nabekent:20150803155847j:plain

労いの肉!の図(ごちそうさまでした!!!!)

OSCON 2015に参加してきました

f:id:lestrrat:20150720110743j:plain

OSCON 2015に参加してきました。実はOSCONは初参加です。

f:id:lestrrat:20150721123220j:plain

場所はオレゴン州ポートランド。アメリカ北西部の町です。着いた週末は熱波に襲われていたようで地元の人達は暑さにあえいでいたようですが、東京から来た自分は「湿気がないだけでずいぶん過ごしやすいな」程度の感想でした。滞在中は天気にも恵まれ、大変過ごしやすかったです。反面熱波が落ち着いてくると、夜はかなりひんやりした感じでした。

f:id:lestrrat:20150721050701j:plain

一般客のチェックインはセルフサービスだったようです。私はスピーカー枠だったので別部屋でした。OSCONで少し印象的だったのは、かなり明らかに参加者の中にヒエラルキーのようなものがあり、一般参加者、スピーカー、スポンサー、とかなり提供されるサービスに差があったということです。仕組み的には当然だとは思うのですが草の根活動的なカンファレンスばかり主催していたので印象に残りました。

最初の二日間はチュートリアル等がメインです。チュートリアルは一枠3時間のものと6時間のものとあり、かなりガッツリ行われている印象です。自分は諸事情によりほとんどこれらには参加していませんが、ミーティング等の間にMesosのチュートリアルに参加してみたりしました。

ハンズオンセッションだったのですが、講師の方々はプロのエンジニアですがプロのチュートリアル講師ではないので進行に若干不満が残りました。内容はなかなかおもしろいものでした。ちなみにほんの一昔前までは聴講者にチュートリアル用の環境を用意するのはなかなか大変な事でしたが、今は「Vagrantを入れておいて」程度の周知をした上で6GBくらいのイメージを渡せばそれで済むのですからバーチャリゼーションやコンテナ技術に感謝感謝といったところです。

f:id:lestrrat:20150720101208j:plain

聴講している以外の時間は主に来場者達と色々な話をするか、自分のスライドの準備に費やしていました。去年日本で会ったDave Cheney氏や今年のYAPC::Asia Tokyo 2015で来日予定のCasey West氏とKelsey Hightower氏にも会うことができました。

f:id:lestrrat:20150721044148j:plain

会期中はずっと昼食が提供されていました。かなり広めのホールにテーブルがずらりと並べられ、プレートをもらってセルフサーブで盛ったご飯をテーブルでいただく感じです。

f:id:lestrrat:20150721051607j:plain

自由に情報を貼り付ける事ができるボードがあり、ここで求人や求職活動が行われていました。こういうオープンな活動はもっと日本でもやれればいいのになーとは思うのですが、やはり文化の違いですね。

f:id:lestrrat:20150721051620j:plain

なおその横にはBoFの集まりを知らせるスケジュールもありました。こちらも空いている時間に自分で企画した集まりを告知して参加者を募ることができます。

f:id:lestrrat:20150722101903j:plain

こんな落書きスペースもあります。

f:id:lestrrat:20150722022646j:plain

二日目はOSCONタイミングを合わせてkubernetes 1.0 のリリースを記念したkuberconが開催されていたのでそちらも覗いてきました。やはりみんな気になるようでかなり盛況でした。

f:id:lestrrat:20150721094501j:plain f:id:lestrrat:20150721095156j:plain

チュートリアルの最終日夜には「Ignite」という名称のLightning Talkです。このセッションではスライドは20枚のみで15秒ごとに強制的に切り替わり、確実に5分で話は終わります。運営側の無駄に時間を長引かせないための努力が見られる形式でした。

f:id:lestrrat:20150721095858j:plain

なお発表者の女性率の高さが印象的でした。これが「印象的」となってしまう事実はカンファレンス運営者としては反省しなくてはいけないですね。

三日目からキーノートと一般セッションが始まります。朝一番のブロックのキーノートではPaul Fenwick氏とAllison Randall氏のトークがなかなか印象に残りました。どちらも動画が提供されています


They&#39;re Here. What Now? - Allison Randal Keynote ...


The Future is Awesome - Paul Fenwick Keynote ...

セッションは12トラックもあるのですが、その合間合間には様々な企画が催されています。

f:id:lestrrat:20150722091353j:plain f:id:lestrrat:20150722091914j:plain

Expo Hallではいわゆる展示会的な催しがあり、時間によっては軽食も振る舞われていました。

f:id:lestrrat:20150723042801j:plain www.oscon.com

自分のトークはこれまで自分がYAPC::Asia Tokyo等で発表してきた物の英語版だったのですが、今回参加してみてこのチョイスは若干ミスだったと思っています。

OSCONは良くも悪くもすでに一大展覧会であり、オープンソースの意義や啓蒙についてのイベントです。現場エンジニアのレベルの話より業界を変えていく話だったり、業界全体の技術トレンド等について興味がある人が集まるということです。その中で技術そのもの、しかも言語間の根源的なトピックについて話すのは微妙だったな、というのが正直な感想です。次回参加する場合はそのあたりを踏まえ、もう少し上のレイヤーの話を用意して行こうと思います。

www.oscon.com

イベントの楽しみ方としてはやはりトークそのものよりトーク前後に関係者を捕まえて四方山話をするほうが遙かにためになりそうでした。トークの内容に関しては技術的に細かい話はそれほど多くないので、トレンドを読み解くという意味ではスケジュールを見れば見えてくるものがあるのでそれで事足ります。さらに突っ込んだ話はパーティーやレセプション、そして廊下での会話の中でしか得られないという気がします。

f:id:lestrrat:20150722030714j:plain

ちなみに今回のテーマは明らかに"Cloud Native Applications"とKubernetes, Mesos, Docker等を用いたマイクロサービスアーキテクチャだったと思います。正直に言うと業界トレンドとしてはそうなのだと思いますが、現場でコードを書いている身からするとわりと今更感があったので、それを五日間繰り返し繰り返し連呼されるのは最後にはおなかいっぱいという感じでした。

おまけ

ポートランドダウンタウンのKenny and Zuke's のルーベンサンドイッチが超絶うまかったです。

f:id:lestrrat:20150720113757j:plain

あと偶然会場までの経路にベトナム人街があったので、会場以外でご飯を食べるときはそこでフォーを食べていました。日本のフォーもおいしいのですが洗練されすぎててなかなか納得がいかないので、アメリカで手に入るフォーが大好きなのです…

というわけで色々楽しいポートランド滞在でした!

English as a Second Presentation Language という取り組みを始めてみました

HDEでは近いうちに公用語が英語に切り替わるということもあり、月一のテクニカルセッションは英語だったり、ミーティング等も英語だったりします。そのようなわけで英語に触れる機会はそれなりに多いのですが、やはり議論や質問をする場があったほうがいいなぁと思い新しい取り組みを始めてみました。

アメリカンスクールに通う子供で英語を(十分に)しゃべれない子供はESL (English as a Second Language)というカリキュラムに入れられてまず英語を重点的に勉強させられるのですが、それにひっかけて "English as a Second Presentation Language"として、プレゼンを通して英語の疑問をぶつけたりそれに答えたりする企画です。これまでもいくつか英語でプレゼンをする集まりはあったと思うのですが、具体的な質問をしたりプレゼンに対してのフィードバックをする時間を設けよう、というのが趣旨です。ちなみに私は小6の時に海外に引っ越しした際にアメリカンスクールにぶち込まれ、ESLに1年間在籍した経験があります。

f:id:lestrrat:20150721082237j:plain

今回は初回ということでまず私がどういうことを気をつけるべきかを含めた話をさせてもらったあと、社内から次のテクニカルセッションで登壇する予定の二人から練習をする形で発表をしてもらいました。

私の発表は以下に置いてあります。読まれる場合はスピーカーノートを開きながら読んでいただくとよいかもしれません(プレゼンテーション表示中に"s"を押してください)。

いくつかのポイントとしては

  • 英語の細かい規則にこだわるより観客に伝えることを考えよう
  • 得意でない言語でプレゼンをするなら、プレゼンの基本的なテクニックをより意識しよう
  • 具体的なtipsをいくつか

というようなことについて語らせていただきました。

プレゼンテーションのあとは質問タイムで、20〜30分ほど質問を最初は英語その後日本語で受け付けて答えたりしました。この英語で質問をする、というのが意外と重要なのでこれをもっと推していけるような仕組みを作るべきと感じました。もちろん日本語でも良いんですが…

その後は社内の二人からの発表。本来はこちらのほうがメインのコンテンツです。発表がおわり、これまた10分〜20分ほどのディスカッション時間を設けました。発表者と聴講者両方からの質問がありました。ディスカッションの内容は発表の内容、言い回し、時制についての注意等が出ていました。

なお本番は1週間後ということもあり、まだ準備中のスライドでしたが、だからこそこのタイミングで英語やプレゼンの構成をみんなでディスカッションする意義があると個人的には思っています。

今回は初めての回ということでとりあえずどうなるか見るために徒手空拳で開催してみました。主催側からの次回の改善点としては

  • もう少し発表者・聴講者から質問等を出しやすい(強制的に出す?)フォーマットを作る
  • ディスカッションに参加しやすいように事前準備をする
  • なんとかして英語で質問をしてもらう

というような事を考えました。ともあれ、第一回としてはなかなか良い感じだったと思います。

うまく回るようになればもっと一般から参加者を募って開催したいと考えていますので、もしこのような企画に興味がある場合は是非私(@lestrrat)のほうまで連絡ください!

はじめての障害演習

どうもこんにちは。 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 が豊富なため、オープンソースでも使い方次第では、 必要な監視を網羅できると考えています。