本番用はこちら http://www.slideshare.net/tagomoris/devsumi2014-tagomoris

1. 社内システムの
構造と設計、実装のはなし
Developers Summit 2014 [13-B-3] #devsumiB
2014/02/13
@tagomoris (TAGOMORI Satoshi)

2. TAGOMORI SATOSHI (@TAGOMORIS)
LINE CORP.
DEVELOPMENT SUPPORT TEAM

5. まとめ
社内システムほど他システムとの連携を考えよう
つまり機能をAPIとして公開しよう
社内システムではHTTP JSON APIを使おう
実装は必要なところから、必要なだけやろう

6. Webサービス今昔
Web2.0 とかマッシュアップ全盛期
OAuth 全盛期
WebAPI 制限期

7. Open WebにおけるAPI
トラフィック・レスポンスタイム
誰がコストを払うの？
互換性
API提供元もやり直したくなることは(よく)ある

8. 社内システム
非公開サービス
性能よりも機能
長いライフサイクル
想定ユーザは「自分」

9. 社内システムの機能
認証
情報共有
資産管理
プロトコル変換
動作状況モニタリング
便利UI提供
データ蓄積
バージョン管理
可視化
……。

10. 何が問題なの？
情報と権限の分断
どこになにがある？ どこで検索すればいいの？
情報と機能の冗長化
同じ社内でいくつパスワード持たせるんだよ！
利用者の効率を考えないシステム
勤怠入力300人の労力 >>>> 人事3人の労力
自動化の妨げになるシステム
そこにしかない情報の参照にマウスクリックが必要
「全部入り」でアップデート不可能なシステム
UIを持つシステム → クライアント更新も不可に

11. 社内システムの連携
DBを見る
SOAP! CORBA!
猫も
子もSOAという時代があったんじゃよ
Enterprise Service Bus
RPC Protocols
Protocol Buffer, Thrift, XML-RPC, ...

12. Make it simple!
権限: 分断を最小限にしよう
全員参照できてよい情報がほとんどでは？
機能: 複数の参照方法を最初から考えよう
ブラウザでの参照 + APIとしての参照
ブラウザも同じAPIを叩くのが最もシンプル
モジュール化: 単機能システムを連携させよう
アップデートが容易な状態を保つ

13. 1.
社内システムほど他システムとの連携を考えよう
機能をAPIとして公開しよう

14. Closed WebにおけるAPI
トラフィック・レスポンスタイム
データ量が通常小さく問題になりにくい
誰がコストを払うの？
会社！
互換性
これが最大の問題
API互換性を維持 + UIのアップデート？

15. APIの互換性
プロトコルの互換性
データ構造の互換性
データそのものの一貫性の維持
クライアント要件の普遍性/不変性

16. Protocols of internal API
Thrift, Protocol Buffers, MessagePack-RPC
IDL
Performance
FTP, RSH, SSH
HTTP
SOAP, XML-RPC, MessagePack over HTTP
JSON

17. 長期運用を前提にしよう
アップデートの容易さ
出力部分のシンプルさ
データ内容把握の容易さ
見ればわかる！
テストの容易さ
curlで叩きたい

18. テスト容易性まじだいじ
自動テストではなく、人が試す、こと
百聞は一見に如かず
ちょっと試して何が返ってくる、何が見える
100ページのドキュメントより1回のcurl
パフォーマンスより大事
Facebookですら、RPCはHTTPでよい (ex:presto)
疎結合

19. 2.
社内システムではHTTP JSON APIを使おう

20. 実装
社内システムですよ
自分達で作り、自分達で使います
動くことが大事
ドキュメント、大事？

21. 優先度
使う機能、使わない機能
顧客相手なら「こんなこともあろうかと」
自分相手なら？
いま欲しい機能
簡単に実装できる、いますぐには使わない機能
欲しい気がするけど、微妙な機能

22. 優先度ハック
まあ、忙しいよね
それ、本当にJSON APIひとつ追加する30分も割
けないくらい忙しいの？
機能の追加ってそんな簡単じゃないよね
UIなしでSELECT結果をJSON出力するだけが本
当にそんなに難しい？
疎結合モジュールの集合にする
単機能追加の時間単位を切り刻む

23. 逆優先度ハック
切り刻まれた細かい機能追加タスク
それ、今いらないなら後でやればいいのでは？
だっていつでもできるでしょ
後でやればいいなら、今後何が必要か考えなくて
いいのでは？
(将来の)要件定義は難しい、なら後回しにしよう

24. 3.
実装は必要なところから、必要なだけやろう

25. アーキテクチャと
開発・運用の関係
アーキテクチャの割り切りが開発・運用を加速する
開発・運用の前提がアーキテクチャをシンプルにする

26. ビジネスへのインパクト
社内システムほど試しやすい場は無い
誰か損する？
誰もが得するでしょ？
顧客は自分
自分が嫌なものは作らないでしょ？
自分が使いたいものを使えるでしょ？

27. TO MAKE IT SIMPLE
MAKES OUR OWN ENVIRONMENTS
BETTER THAN BEFORE.
LET’S DO WITH YOUR OWN SYSTEMS!