Cybozu Tech Conference 2016に行ってきたときのメモです。

タイムテーブル

14:10〜14:35 「サイボウズの現在と未来」
14:40〜15:05 「kintoneの開発プロセスとプロジェクト管理ツール」
15:15〜15:40 「cybozu.comの認証」
15:45〜16:10 「バグの調べ方」
16:20〜16:45 「とある脆弱性の永い議論」
16:50〜17:15 「SREチーム発足！」
17:25〜17:50 「開発者を支える生産性向上チームの取り組み - CI, Browser Test, Tools and Infrastructure」
17:55〜18:20 「サイボウズのリモートワーク・リモートチーム」

「サイボウズの現在と未来」

資料

サイボウズの生い立ちから現在までのお話。

過去

愛媛で発足。まだWebが一般化する前の1997年からグループウェアを手掛ける。
teppeisさんが入社したころから売上低迷、色々試行錯誤が続いた（社内ではこの時期を「大航海時代」と呼んでいるとのことw）
大航海時代からcybozu.comのリリースをきっかけにV字回復
同時に離職率は2005年の28%から2015年は4%に改善させた
それは地道なKAIZEN活動の結果か。参考スライド：サイボウズの開発を支えるKAIZEN文化
http://www.slideshare.net/teppeis/kaizen-68803503

現在

社員数は
全体で600名
グローバル開発本部200名
ベトナムオフショア 30名
cybozu.comのユーザ管理など基盤部分は各サービスで共通化している。
cybozu.comのリリースから数年が経ち技術的負債も溜まってきている。
アーキテクチャ刷新プロジェクト「Neco」の紹介
http://blog.cybozu.io/entry/2016/03/11/080000

今後

Elasticsearchまわりを改善したい
- Solrの運用上のつらみ
- インデックスは10TBを超えている
KintoneはMySQLベースに、Virtual Tableという中間構造を持っている。
新アーキテクチャはVirtual Tableの部分をElasticesearchに置き換えようとしている
認証基盤の強化
　- 2要素認証のの2要素目をいろんなデバイスで
CDの推進
分散ストレージ/バックアップWeb
ログ解析基盤など

「kintoneの開発プロセスとプロジェクト管理ツール」

資料

複数バージョンの開発をGitで行なっている。
- バージョンのブランチから各開発者がフィーチャーブランチを切って開発している
プッシュ時、マージ時にテストを走らせてパスしないと先に進めない仕組みにしている
push > Webhook > 静的解析 > 単体テスト > マージ可能
マージ > Webhook > 静的解析 > 単体テスト > 受け入れテスト(Selenium) > ドッグフーディング環境へデプロイ
Jenkinsでビルドパイプラインを組んでいる
ドッグフーディング環境
- マージ後30分ぐらいで反映される。業務で使用してドグフーディング。
Kintoneの開発チームはKintoneだけで、ドキュメント管理、TODO管理, スケジュール管理、コミュニケーションしている
チームを跨いだ情報共有もKintoneでやっている。
自動テストはChromeだけでやっている。

「cybozu.comの認証」

資料

サブドメインでテナントを識別
共通基盤でSSOを実現
cybozu.comの各サービスは1つのログイン画面で認証可能
当初は各サービスでセッション共有やログオフさせるのが課題だった。
現在は共通基盤でログインしたらKVSにセッションを保存してサービス感で共有している
ただ仕組みが複雑になってしまった、なぜか？
オンプレ版プロダクトの機能を再現する必要があった
色々な企業のセキュリティ要件に対応するため
SAML
- SSOの標準仕様
- ブラウザ経由で認証サーバーとやりとりするので、認証サーバとの直接連携しないメリット
社内ハッカソンで顔認証を実装してみたとのこと（デモあり）
- Windowsに顔認証する仕組みがあるらしい。写真では認証できないようにWindowsがやってくれるらしい

「バグの調べ方」光成滋生

資料

登壇者はサイボウズ・ラボに所属する暗号化の本を書くようなガチな方
phpのOPCache周りのバグを見つけてパッチを送ったり、カーネルレベルのバグを調べるようなかなり低レイヤでのバグの話でした。
社内にこういう人がいるのは強みだなと思いました。

バグの調べ方まとめ

まず自分たちのコードを疑う
論理的に、時にはひらめきで追いかける
辛い時でも耐える（気分転換でもして）
だそうです。

「とある脆弱性の永い議論」

資料

CVSSの評価や脆弱性の届け出などしているセキュリティチームの人
チームは東京7名、上海3名の10名体制
PSIRT(Incidentは別チーム）
- Product security ~~Incidente~~ Response Team
自社でのセキュリティテストに加え、脆弱性報奨金制度を設けている。
脆弱性報奨金制度
外部のバグハンターの力を借りて、脆弱性をより早く発見し、改修することを目的として2014年から開始。
最近は報告数も減り、支払う報奨金は減ってきている。
最初の年はXSSやSQLiなどの典型的な脆弱性の報告が主だったが、最近はBlack HatやAppSecなどで報告された事例の横展開が主になってきた。
複数のCSRFを報告されたが、認定するしないは都度ジャッジ
認定するかの基準を設ける必要があり脆弱性認定ガイドラインを作った
PDF Formcalc Attackの報告
被害者が利用するサイトにPDFを仕掛け、ダウンロードさせPDFに仕込まれたスクリプトがダウンロードしたサイトで実行されてしまう脆弱性
Adobeに報告したが同一ドメインでスクリプリトを実行できるのは仕様との回答（クロスドメインは対策している）
脆弱性に認定して自分たちで対応した。
RFDの報告(Reflected Filename Download)
情報セキュリティのCIA（機密性、完全性、可用性）
最近では社内で脆弱性を検証しても不具合が出にくくなってきたそうです。
こう言った取り組みが珍しいのでメディアへの露出も結構あったり、脆弱性への知見を得られるメリットも大きいとのこと。

「SREチーム発足！」

資料

Site Reliability Engineer - サイトの信頼性を向上させるソフトウェアエンジニア/チーム（コードも書く！）
SREというのはGoogleが提唱しているものです。
レプリケーションできるmemcached　yrmcdsを作ってオープンソースにした(http://blog.cybozu.io/entry/5436)
DDOS対策、現実的な数字で同時アクセス数を制限した。
最近はGOでツールを作っている
監視対象が1000台を超え、Zabbixでは辛くなってきたのでdatadogを検証している
artifactory
presto(hadoop)
- アクセスログの集計が13時間から20秒に。
NVME SSDの導入

SREチームを作った訳

サービスイン当初は全員で運用も開発もしていた。
DevとOpsを分けたが問題が。

現在の課題は
　アーキテクチャが古くなっている
　ストレージ周りが特にやばい
今後やりたいこと
　ログ収集、分析基盤
　検索基盤
　デプロイ
　サービスディスカバリ
　リソースプール
　分散基盤

「開発者を支える生産性向上チームの取り組み - CI, Browser Test, Tools and Infrastructure」

資料

生産性向上チーム設立

開発基盤周りが共有されておらず、各チーム同じような試行錯誤をしていたため設立
ノウハウの集約と展開
- 各チームを巻き込んで改善していく

Jenkins

共通で使っているJenkinsが巨大になりカオスになってしまった辛い
Jenkins本体やプラグインのアップデートも困難な状態
誰かがプラグインをアップデートすると関係ないチームのビルドがこけ阿鼻叫喚。
他のCIツールも検討したが、Jenkinsのプラグインへの依存が強すぎて一旦は断念した（後に対応した）。
そこで１チーム１Jenkinsにした。
- 他チームを気にせず運用できる。
- 責任が明確
- トラブルが減ったので逆に管理コストが減った
ほかにもビルドスクリプトのカオス化問題
- Jenkinsの設定がバージョン管理されてない
- grepもできないので調べにくい
- Githubにスクリプトを置くようにした

ブラウザテスト

40並列でブラウザテストを動かしたいが、実行環境のリソース確保が難しい
社内のマシンで管理するのは無理なので、Google Cloud Platformに持って行った。
GCEは10分単位の課金なのでコスパが良い（awsは1時間単位で課金）
- 月に200ドルぐらいで済んでいる
お金の力でスケールする
モバイルはSauceLabsのようなTaasが必要になる

DNS自動設定

KintoneにDNSのアプリを実装した。
情シスに依頼するハードルがなくなりDNS活用度が上がった
http://blog.cybozu.io/entry/2016/02/16/080000

クラウドサービス試したい問題

殆どのシステムはオンプレミスで運用していた。
- オンプレだったのはセキュリティ理由ではなく、社内検証機と接続しやすくするためだったそうです。
少人数の新規プロジェクトでクラウドサービスを実験してみた
これまではGithub Enterprise使っていたが、外部システムと連携しづらいのでgithub.comのprivate organizationを利用
他のクラウドサービスとの連携が楽に。

Wiki

これまではオンプレ版のConfluenceを使っていたがGithub Wikiを使うようにしたら結構良かった。

やっぱりJenkinsは辛い（再燃）

Circle CIを試した。設定が楽。
cron的な定期ジョブ書けないけど工夫で乗り切れる

通知

社内システムだと外部からの通知を受け取れないのでSlackを使った。
Slack
エコシステムが発達しているのが採用の決め手
botを作る仕組みも用意されているので拡張が容易

自動テストのコードカバレッジ

計測しても殆どの人が見てなかったので。codecovを導入。
コードカバレッジを可視化するサービス。
プルリク時にカバレッジ変化を投げてくれるので嫌でも見ることに。

依存パッケージのバージョン管理

VersionEye
最新でないパッケージを検知してくれるサービス
他にもライセンス問題（パッケージ間のライセンスの矛盾など）やセキュリティ問題も検知してくれる
主要な言語やパッケージマネージャはサポートしている
クラウドサービスのデメリット
社内システムと連携しにくい
ユーザ管理が必要
クラウドサービスに持ち出して良いデータの判断

「サイボウズのリモートワーク・リモートチーム」

資料

離れた場所でも最高のチームワークを実現する方法ーサイボウズ開発チームのリモートワーク事例ー
http://www.slideshare.net/teppeis/remote-work-in-cybozu

チーム内で情報格差があるのダメ。
些細な情報こそ重要。他拠点に届かないのダメ絶対。
Web上に文書を残す。効率が悪いのはその時だけ、後から役に立つ。
完全リモートでの採用も始めようとしているとのこと。

今回、東京-大阪-愛媛の3元中継でしたが、さすがにリモートワークしてるだけあり手慣れた感じでした。

所感

「登壇者の職種がバラバラすぎて全ての発表を楽しめる人はいないかも」、サイボウズの方は心配されてましたが、そんなことはなくむしろ色々聞けて面白かったです。次回も期待してます！