サービス運用者のための継続的監視

YAPC

@myfinderさんのRejectConf。

DeNAで監視しているらしい項目

当たり前レベル
これくらいはやっててもおかしくない（と思っているらしい）レベル
  • アプリの起動確認
  • httpd.conf（！）
  • my.cnf（！）
  • show variables like ‘hoge’の値
これやってる？（どやっ）なレベル
  • カーネルの挙動
  • ディスクに書き込みが出来るか

nagiosのプラグインはガリガリ書いてもらっている

exit 2＝critical、exit 1＝warning、exit 0＝正常、というexitさえすればどんな言語で書いてもいい。新卒にもガリガリ書かせている。
たくさん監視項目が増えて(ﾟдﾟ)ｳﾏｰ

監視は継続的なテスト

監視項目が通らない、と言うことは異常があるということ。異常があるということはリリースできないということでもある。リリースできた時にオールグリーンだったという項目を、常に監視していくということは継続的にテストをしていることと同じ。

感想

confやカーネルの監視をするという感覚は全くなかったが、よく考えるとクラックされてTRACEメソッドが許可されていたりとか怖いし、障害が発生してmysqlの変数変えて、でもmy.cnf変え忘れてて、再起動してリセットされて障害再発ー！とかありそうだなと。

プロダクト系のサーバ新設で、設定箇所ごとの確認を目視ではなくてnagiosベースとかでやると、素人だろうが新人だろうがテストが通ればOK！投入可能！っていう状態になるので、スキルセット関係なく仕事を頼めそうな気がするし、クオリティ管理が楽になりますね。同じようにインフラチームでも同じように使うと面白そう。

テストドリブン運用ー！！！

超個人情報のためのマルチクラウドを用いた分散セキュアストレージ

YAPC

前夜祭でのRejectConfです。http://yapcasia.org/2011/talk/81

暗号化の一般的な方法

Rijndaelを使ったAESが一般的。

AES_ENCRYPT(‘hogehoge’,'key’)

だけど、これだとKEYも平文もbinlogでだだ漏れなので、非常にセンシティブな個人情報（病気の情報とか、クレジットカードとか）を扱うときには怖い。

各要素を別クラウドに保存する

そこで、インデックスと暗号化キーと暗号化されたvalueを別々のクラウドに保存して、webサーバからそれぞれを呼び出して復号化して表示する、ということをやっている。

みたいな。でも、これだとAWSが落ちたらｻｰﾋﾞｽ＼(^o^)／ｵﾜﾀになってしまいます。

データセットを3セット作って冗長化

ということで、同じデータを3つのクラウドに保存して、どれかのサービスが落ちても、残ったデータセットを参照してサービスを継続できるようにしています。

という感じで。これなら、どれが（同時に2つまで）落ちてもサービスが継続できますね。

感想

確かにAES_ENCRYPTを使うことを推奨しているので、かなり参考になりました。

データセットを同じインスタンスに3セット置くと、1サーバと同じじゃん！とは思いましたが、実際に1インスタンスに置いているかは不明。もしやるのであれば、3インスタンス×3サービスという感じで設計したほうがよさそうです。

著作権侵害判断の難しさ

NAVERまとめがgoogleからAdSense配信を止められたというニュースが出ていた。

「NAVERまとめ」にAdSense配信停止　理由は「著作権侵害動画」だが……

配信停止の是非はさておき、気になったのはこの部分（引用は上記リンク先）。

　こうしたコンテンツのまとめで“著作権侵害”を指摘されると「キュレーションが成り立たない」上、ガイドラインが不明確なものに依存してしまうと「安定的なサービス運営は難しくなる」と他の選択肢を検討していた矢先だったという。

つまりは、「まとめコンテンツを見ても、それが著作権侵害なのかどうかわからないから、それをガイドラインにされると困るよ！！」ってことなのですが。
ガイアックスでも投稿監視事業をやっているので、この類の話はよくいただくのですが、非常に難しいところなのです。

著作権侵害判断が難しい理由

個人によって判断基準が異なる

例えば
「有名人なら削除してください」
と言われテも、その判断をする人がすべての有名人を知っているわけではありませんし、そもそも有名人って何よ、という事になります。
例えば僕なら、「ルーカス・ラデベ」という人は、リーズユナイテッドで活躍した大変有名な尊敬すべきサッカー選手である、と言えるのですが、国内のサッカーファンであっても彼の名前を知っている人はほとんど居ないでしょう。テレビを見ない人にとって、「キリンレシーブ」と言ってもハァ？ってなるのと同じですねｗ
自分の興味のない分野と興味のある分野では、「有名」の深さが大きく異なるわけです。

記事だけでは判断できない

「ジャニーズ事務所の所属タレントだったら非表示にしてください」
「ディズニーキャラクターだったら削除してください」
などという話があるとしても、写っている写真がジャニーズ所属のタレントなのか、載せられた画像がディズニー作品かどうかって、記事を見るだけではわからないわけです。
極端な例では、アンディ・ウォーホルのマリリン・モンローの絵、これがマリリン・モンローの許可を得ているのか、作品を見るだけではわからないわけですね。

一方、一見して分かるものも多い

まあ・・・著作権侵害の対象として槍玉に上がるのは、そういった微妙なところではなくて、まとめコンテンツを作ったらアクセスが来るような超有名人だったり、人気の作品・人なのですから、googleは「そんなの分かるだろ！」と言っているとも言えます。
（とはいえ、「明らかに分かる」を定義するのはヒジョーに難しいわけですが）

バランスを取ることの難しさ

著作権を守ることはもちろん大切なのですが、サービス提供側にとってはコンテンツを作りやすくして、たくさん作ってもらうことも重要です。まとめてもまとめても片っ端から削除されてしまったり、画像を貼ることが出来ずに全部リンクになってしまったりすると、ユーザからは魅力的なコンテンツにはならないわけですね。

インターネットでの著作権

今までの著作権って、紙やDVDみたいな媒体がありましたが、今ではリンクすればそのコンテンツにアクセスできてしまいます。
無許諾で全文引用というのは論外ですが、imgタグを使って画像を抜いて引用明記する場合や、NAVERが言うようにyoutubeでOKって言ってる著作権侵害動画をで埋め込んだ場合の責任はどちらにあるのか（NAVERはgoogleだと言っているわけです）、など、どんどんわけわからなくなってきます。

ユーザーとしては気をつければいいのですが、サービス提供者としては頭がいたいですね。

物事を試し、かつ、疑ってかかること

こういう姿勢はいいですよね。

「魔法の数字8.8.8.8」を検証する
ここ数日、8.8.8.8や8.8.4.4というIPv4アドレスを持つGoogle Public DNSに関する話題が盛り上がっているのですが、多くの人が「よくわからないけど設定変更したら早い！」と言っているので、そこら辺の話を調査してみました。

「8.8.8.8が早い」という話を聞いてすぐ試してみる、というのはどんどん推奨したいところですが、「8.8.8.8が早い」をそのまま鵜呑みにしてしまうのは考えものです。

  • 常識だと思われていることに疑問を持つ
  • 疑問を検証する方法を設計して検証する
  • 結論を得る

というのは、研究だろうが企業活動だろうが必要なステップですし、この検証の中で彼はいろいろなものを得たと思います。協力される人脈、技術に対する知見など。

こうありたいものです。

良心と科学技術

僕は広島出身なのですが、子どもの時から人間の良心について深く考える機会が、必ず年に1回やってきます。8月6日、原爆の日です。

今では誰もが良くないと思っている核兵器を、同じ人類の上で炸裂させた日です。
その関連で科学技術の使い方についてお話しようと思います。

科学技術の二面性

現在では核兵器は良くないとはみんな思っていると思いますが、核兵器は良くないけど、平和利用はいいよね、という感じで原発が推進された側面もあるかと思います。

科学技術は表裏一体です。
殺虫剤を作れば毒ガスもできますし、原子力を使おうとすると核兵器も作ることができる。科学技術を使う人の良心が非常に大切。良くないと思ったことは絶対にやらない。そういう強い気持ちが必要です。

良心と強い気持ち

原発の話を続けますが、良くないと思ったことをやらない、というのは結構難しいことだと思います。

M7くらいの地震が来ても大丈夫なように作っています、M8が来たらダメだけど、そんなの来ないよね。10mくらいの津波までなら大丈夫なように作っています、15mが来たらダメだけど、そんなの来ないよね。

そうやって、人事のように考えた結果、いざ、が起こったときに大惨事になってしまったわけです。自分が責任を自分のことのように感じる事のできる範囲を少しずつ狭め続けた結果、全部ひとごとになってしまったわけです。

人の器の大きさは、責任を、自分のことのように感じることができる範囲です。それが家族でもよいでしょう。
同じチームでもよいでしょう。会社でもいいかもしれません。出来れば社会に広げたいものです。

しかし、便利だから、売上になるから、と自分の責任だと感じる事ができる範囲を超え、
現実に妥協してしまって良心を裏切ってしまうと、自分の取る責任範囲を狭めてしまうと、その積み重ねで大惨事につながってしまう。

自分の実力をつけ、それ以上に自分の責任範囲をめいっぱい広げないと、科学技術はうまくつかえないのです。良くも悪くも、現在はそれをエンジニアに痛烈につきつける世の中です。気を付けていきたいですね。

けれど時間は有限

一方で、自分の身にはいつ何が起こるかわからない。そんな中で早く結果を出したいと思って、つい妥協を許してしまうかもしれない。しかし、強い心でそれを跳ね返しつつ、日々を一生懸命過ごさなければならないですね。

このBlogについて

このBlogについて

私について

名前：藤堂和幸
所属：株式会社ガイアックス 運用技術部 マネージャー＆採用担当

多分実名を出してBlogをやるのは初めてだと思います。
エンジニアではありますが有名でもありませんし、じゃあ他の分野で何か秀でているかというと、わかりません。それでもガイアックスでの私の経歴をご紹介すると、

  • 2000年 ガイアックス入社。京都で学生向けの研究開発拠点「京都ラボ」をid:hidehigoと協力して設立。
    • ラボの運営、広報、プログラムのお勉強をしながら大学で再生医学の研究やっていました。
  • 2001年 営業職として上京。
  • 2004年 開発職に転向、オンラインゲームのPMとしてタイトルの立ち上げを行う。
  • 2007年 運用をミッションとする運用技術部の立ち上げをid:j4590と共に行う。
  • 2010年 技術系にフォーカスした新卒採用を開始。

Twitter ：http://twitter.com/frecce/:@frecce
Facebook：http://facebook.com/kazuyuki.todo/:kazuyuki.todo

このBlogについて

タイトルのI have nothing (but) TODOは、何もエヴァンゲリオンが好きだからこうしたというわけではありません（好きですが）！
ダブルミーニングでして、

  • I have nothing but TODO
    • 僕にはTODO（藤堂＝自分自身）しかない。自分がやらねば誰もやらない。
  • I have nothing TO DO
    • 僕には何もすることはない。みんなが力を発揮してくれれば、自分なんかがやることは何もない。だからみんな成長してくれ！

という2つの意味をかけています。
自分自身、エンジニアやマネージャーとしては成長しなければなりませんが、マネージャーは部下が自分以上に成長すること、また、自分よりも優れている人を正しく評価して力を発揮していただくことが必要ですから、自分よりも他人を優先する場合もあります。
僕はつい自分が、自分が、となってしまうので、その戒めです。

つたない文章で恐縮ですが、お付き合い頂ければと思います。