第１回Kichijoji.rb レポート

2015/3/11(水) に第1回Kichijoji.rbが吉祥寺のPicoPico Cafeにて行われました。

そのときの様子をざっくりレポートしていきます。内容の細かいところは各スライドや別途各自がブログを書いてくれると思うので、そちらをご覧ください。

アジェンダはこんな感じでした。

• 第1回Kichijoji.rbの挨拶 by Chris Salzberg
• Data Encryption with Amazon KMS by Kazunori Kajihiro
• Hound CI について by Masahiro Saito
• ngx_mruby について by Taku Nakajima
• 雑談

19:00から開始予定でしたが、集まりを待っているとかでだいたい19:15過ぎくらいから始まりました。それまでは各自まったりしてる感じで。PicoPico Cafeさんは無線も使えたので良かったです。

第1回Kichijoji.rbの挨拶

弊社のChrisから、Kichijoji.rbを開催することにした趣旨の挨拶から始まりました。 Kichijoji.rbは、弊社デジカと同じく吉祥寺にあるKrayさんとで企画して、吉祥寺からRubyなどエンジニアコミュニティを盛り上げていきたいということで、始めることにしたとのこと。また、弊社には日本人以外の社員も多い（というか、だいたい英語できる）というのもあり、Ruby会議のように日本語、英語関係なくプレゼンしたり交流したりする場にしていきたいということを語られました。

Data Encryption with Amazon KMS

弊社の鍛廣による、クレジットカード番号の保存の仕方とAmazon KMSについて。

デジカではKomojuという決済サービスを提供しています。そこで、クレジットカード番号を保存するというミッションがあり、いかにしてセキュアにカード番号を管理するべきかという説明から始まりました。 PCI DSS v3と呼ばれるクレジットカード業界のセキュリティ基準があり、それに則ってデータを管理する必要があるそうです。そこには、カード番号を管理の仕方を規定しているとのこと。カードデータは読み取り不能にすべしとか、データは暗号化し、暗号化に使ったキーの保存方法や、そのキー自体も暗号化する必要があり、そのキーの暗号化に使うキーは元のキーと別々に保管すべし。とか書いてあるそうです。

で、じゃあ実際にどうやって実現するのか？というのが今回の話でした。そこで出てくるのがタイトルにあるように、Amazonが提供しているAmazon KMSです。

KMS (Key Management Service) は、データの暗号化に使用する暗号化キーを簡単に作成および管理できるサービスで、キーのセキュリティ保護に Hardware Security Modules (HSM) を使用しているとのことです。HMSは、上述のPCI DSSにも記載されている要件にもなります。よって、KMSを使うことにより、この要件も満たされることになります。

ということで、技術的な詳細にはこのポストでは触れません（よくわかってないので）。KSMを使ったKeyの保存方法や取得方法、暗号化、複合化などの説明は、上記のスライドをご覧ください。後日、本人が別途ブログ書くみたいなので、それを見るのがいいと思います。

プレゼン後の質問で、カード番号のような重要なものをAmazonのサービスに頼るのはベンダーロックインされるので、どうなのか？という質問がありましたが、カード番号自体をKMSで管理する訳ではないし、Aamazonと同じセキュリティレベル（技術だけでなく、運用体制も含めて）を構築、維持するのはコストや時間など考慮し、KMSを使うのが良いと判断したそうです。

Hound CI について

次は、弊社の齊藤による、Hound CIの概要とデジカでどのように運用しているのかについての話でした。Hound CIは、Thoughtbotが運用しているサービスで、開発は2012から行われており、公開されたのは2014からとのこと。Githubのプルリクエストベースでコーディングスタイルをチェックしてくれるサービスです。現時点の対応言語は、Ruby, CoffeeScript, JS, SCSS。 今後は、Markdown, TypeScript, Python, PHP, Objective-Cをサポートする予定。Violation Dashboardを提供予定だそうです。 開発は今も活発で、SCSS-LintやES6サポートなど頻繁にアップデートしているとのこと。

料金は、OSS開発はFreeだけど、プライベートリポジトリで使いたい場合は、$12/月かかります。また、ソースを公開ているので、自前でサーバーに入れて運用することもできます。チェックルールをカスタマイズしたい場合、この方法でないとできないっぽいです。なんで、デジカではHerokuに入れて運用しています。

自前で運用する場合の注意点がひとつ。自前で動かしてもStripeの課金画面が表示されるそうです。それを回避するgem(hound_breeder)を作ったので、使ってみてくださいとのこと。

さて、本題。なぜにこのようなツールを入れるのかという話。そもそもは、コードレビュー時のストレスを減らしたいから。レビューをスタイルに惑わされずにロジックの内容や設計などに焦点を当てたい。でも、コーディングスタイルが変だとやっぱり気になる。それは自動化で対応してしまえ。そこで、HoundCIを導入した。

デジカでは、主に2つのサービスを開発しており。HoundCIを導入している。ただし、少し運用方法が異なっている。 1つ目はプロジェクト開始から導入したので、デフォルトの設定で運用を開始した。気になるところは、都度調整していっている。 2つ目は、開発がそこそこ進んだ状態から適用した。そのため、修正点に関係ない箇所でコメントがでまくる。特にシングルクォーテーションとか、しかもspecだったりする。（Houndではシングルクォーテーション使って言いるとバウバウされる）非常にストレスになる。そのため、ルールを緩く設定して、徐々に厳しくしているとのこと。

各自で使っている環境などで、スタイルの好みが分かれてないのか？という質問もあったけど、現在デジカはまだ少人数の開発チームだし、そこまでみんなスタイルにこだわりがないとのこと。今のところは齊藤が自由気ままに運用しているそうです。

ngx_mruby について

最後は、急遽プレゼンを振られた@essaさんこと中島さんのプレゼンでした。中島さんは、アンカテというブログでも有名ですよね。今、デジカでは中島さんにインフラ面でお世話になっており、今回はそこでのNginx絡みの小咄をして頂きました。

Nginxで行いたい処理をrubyでかけるngx_mrubyについての簡単な説明とそれをどのような用途で使ったのか紹介でした。 ngx_mrubyは、これまではmod_perlやmod_luaでやっていたNginxの作業をrubyでできるようになるのがいいとのこと。mrubyはrubyのサブセットでありかなり小さいのと、requireできないので、あらかじめ必要なgemやライブラリはコンパイルしておかないと使えないとのこと。

で、何に使っているのかというと、複数環境で同じプログラム、同じデータを使っていると、どこにアクセスしているのか分からなくなるという問題がある。検証環境でテストしているつもりでも、実際本番サイトだった。みたいな。そのため、アプリレイヤーに関係ない層で環境情報をサイトに表示する仕組みが欲しかった。

ちなみに、現在Blue-Green Developmentで環境を作っているため、BlueとGreenが両方ともProductionになる。そのため、envで何かをするのは今回の用途には合わなかったとのこと。

ということで、Nginxのレイヤーで上記のような仕組みを入れたい、で、ngx_mrubyがいいんじゃないかということになったそうです。

実現方法としては、Nginxのconfigにmrubyを書いており、nginxでmrubyを使うために、Chefを使って、mrubyで使うgemなどをコンパイルしているそうです。

たぶん、ここら辺も本人がブログとか書いてくれると思う。たぶん。

ということで、第1回目は以上4名の発表でした。発表後は、雑談会となりました。

定員20名のところ15人以上はいたと思うので第1回としては、なかなか良かったかと思います。また、インターナショナルなmeet upにしたいという趣旨の通り、英語と日本語が混じるプレゼンだったり、参加者の割合も日本人と外人で7:3くらいでした。だからと言って、英語ができないから敷居高いとかはないよ。

Kichijoji.rbは毎月第2水曜日に開催する予定です。 次回は、2015年4月8日(水)を予定しています。近くなったらDoorkeeperでイベント作りますので、気軽に参加してみてください。 発表者も募集していますので、発表したいネタとかありましたら、遠慮なく声かけてください。