デブサミ２０１４行ってきた：社内システムの構造と設計、実装のはなし
taketnakのメモ＆覚書です。間違いその他ある場合があります。
13-B-3 社内システムの構造と設計、実装のはなし
イントロダクション
LINE株式会社 TAGOMORI氏
開発支援チーム
サービス構築者の手助け
サービス横断で効率化・数値化を行う
メインサービスの他に細かいサービスが複数オープン・クローズしている。
（Livedoorブログなども含まれている）
今日、話すこと
Webサービス今昔
→ Auth流行、支配的に・・・
→WebAPI制限、 Google MAPSの回数制限など
Open Web API
トラフィック、レスポンスタイム（ニコ動のYouTUbe制限など）
コストは誰が払う（大規模使用のコスト）
互換性（変わることへの対応コスト）
社内システム：Closed Web
機能 > 性能 （せいぜい数百人～数万人）
Long Life Cycle（あれば問題ないと問題点を認識しつつ継続される）
Target User:自分（社内の人だが自分がユーザ）
勤怠で30秒で済むものが3分かかると社員全員のコストとして大きいものになる
機能に注力する。
何が問題なのか？
情報と権限の分断 権限管理する人と情報管理する人が別
└ ユーザ権限を設定する人と決定する人が異なる。不便
情報と機能の冗長化
└ 自社システムでもパスワード複数管理・・など
UXの欠如
└ 社内システムほどUXが悪い
自動化の障壁
└ 集積・分散が多いため効率化したいが、当初に自動化思想がないため障壁がある。
└ 個人の情報などアクセスできないものが多い、自動化の障壁
全部いり：アップデート不可能
└ 機能とUIが結合、開発環境の旧式化など様々な障壁
社内システム連携方法
DBを直接見る。
└ 密な結合になり、今後のUPDATEしにくい
CORBA
SOA! → 複雑、成功例あるのかな
└ソフト高い、XMLたくさん・・インテグレーションコスト、ライセンスコストが膨れ上がる
RPC Protocols
- Protocol Buffer,Thrift
- XML-RPC,MessagePack-RPC
- 当初から組み込む必要があるが有効
社内システム連携：Make it Simple！
権限の分断を最小限に
└ 参照そのものに権限はそれほど必要ではないのではないか？
機能
情報には複数の参照方法を。
└ ブラウザで見る、JSON,XML、TXTなどいくつかの方法を持たせる
└ 参照する側はUIがAPIをたたく方法で密になるのを防ぐ。
モジュール化
└ 単機能システムを連携させる
└ アップデートが容易な状態を保つ
└ 売り上げに直結しない、要員継続が難しいので・・
社内システムほど他システムとの連携を考える。
└ 機能をAPIとして公開しよう
└ API自体を保っておけば内部アップデート可能
トラフィック、レスポンスタイム
└ トラフィックやレスポンスで問題になる事は少ない
コストは誰が
└ 会社、問題ナシ
互換性
└ APIをきっちりきることで互換性が保たれる
└ 粗結合なシステムにしておけば個別更新が容易
└ 1画面に複数機能を足した場合、修正による画面全般への影響が大
・API互換性
- データ構造 リストがハッシュになったなど・・
- 意味の一貫性 OKがサクセスになるなどの変更例
- クライアント要件の不変性/普遍性 例）XPじゃないと2003じゃないと・・
ドキュメントに頼りすぎるとメンテナンスが落ちる
Protocols of Closed Web API
Thrift、Protocol Buffers（IDL)
└大規模システムには使うが社内システムには導入コストが・・・
└FTPなど古いからFW超えに苦労するなど・・
└SSH 相手側に認証が必要になるため権限分断する
HTTP 最優先？クローズドじゃないけど・・
SOAP,XML-RPC,.. メッセージパックなどCSV,TSVなど
長期運用
└どのデータどういう意味かどのようなものかわかりやすく持つ必要がある。
└Wikiも5年後使えるかわからないよね・・・
└自分の目で見て確認できるデータが良い。YAML、XMLは人がわかりづらいなど
きちんとアップデートするという事
└テストコードだけでは言語またぎ一貫性などが保たれるか。
└全てのテストコードを残すよりは人の目で確認できる事を確保したい。
テストの容易さ。
└ＪＳＯＮだとテスト容易、コマンドラインから直接確認できる手軽さが良い。
百聞は一見にしかず
1time curl >> >> 100page doc
└1回たたいてみて動作確認できる
easy to try >> >> performance
loosely coupled >> >> strict protocol
└新しい言語にも対応できる疎結合が重要
動くことが大事
まず動いて運用にのせられるものが良い
└× 社内システムは無駄なものは不要、便利機能は負債
実装がラクなAPI
機能を切り刻む 欲しいものから順番に作る
└単体で動くものをそろえていく
修正単位を最小化する
└他の機能と密接にしないことで他の機能理解が不要
逆優先度ハック
└切り刻まれた機能追加タスク
└急な割りこみ作業にも対応可能
└今いらなければ後でやれば良い。いつでもできる。
└後でやればいいものなら必要ないことかも・・
要件定義は難しい だから後回し
積極的にサボりながら必要なとこに手をつける
アーキテクチャと開発運用
割り切りが開発運用を加速
└疎結合にわりきった機能開発
開発・運用の前提がアーキテクチャをシンプルにする
ビジネスへのインパクト
└社内システムほど試しやすい場はない、顧客は自分
└ 新しいライブラリ・技術を試す場所
まとめ
To make it simple
makes our own environments
better than before
lets do with your own systems
感想：
やつぎばやに与えられる情報についていくのがやっと・・・
ただ、ポイント部分（機能を細かくしろ、API化しろ、シンプルにしろ等々）は
繰り返しワードとして強調してくれているのでしっかりとポイントは
印象に残った。
