失礼ながら、モリス節炸裂しまくりで面白かった。話上手だなぁ。
「社内システムの構造と設計、実装のはなし」
- 田籠 聡 氏
- @tagomoris
- LINE(株)
- 開発支援室
LINE
「LINEというサービス、みなさんご存じない方もいらっしゃるとは思いますが(ry」
DevOps, by Ops, for Ops
今日言いたいことは、、、
- 社内システムほど他システムとの連携を考えよう
- 社内システムではJSON APIを使おう
- 必要なものを作ろう
これから1つずつ説明します。
Webサービス今昔
- Web2.0: マッシュアップ全盛期
- OAuth流行、支配的に
- WebAPIの制限
- GoogleMapsのJS APIの制限等
Open Web API
- トラフィック、レスポンスタイムが課題
- ニコ動も最初はコンテンツストレージにyoutube使ってた
- 太平洋横断してTTLが
- コストは誰が払う？
- 互換性
- API仕様が変わると、追従が大変
社内システム: Closed Web
- 機能＞性能
- 性能が問題になることはほとんどない
- せいぜい数百〜数千人
- Long Life Cycle
- 社内システムのライフサイクルは長い
- ライブドアでは、2000〜2001年頃作られたホスト管理システムが
今でも生き残っている(！)(訂正) 2010年には撲滅されたそうです。聞き間違えました。すみません。
- Target User: 自分
- ドッグフードを食べることを意識
社内システムについては、まず機能面に注力すべき。
問題
- 情報と権限が分断
- 誰が何を見れるか、どういう情報を持っているかが、わかりにくくなりやすい
- 情報と機能の冗長化
- 社員名簿があらゆるところにあるとか、同期が一日遅れ・・・
- 自社システムでパスワードを複数持ってる・・・
- UXの欠如
- 自動化の障壁
- スクレイピングできるならまだしも、見ても問題ないはずなのに認証が必要みたいなケースも
- 全部入り: アップデート不可能
- てんこ盛りだと、どうしてもアップデートが遅れる、億劫になる
社内システム連携
- DBを直接参照
- 密結合なので、負の塊を増やす元になる
- SOAP
- まだあるみたいだけど、なかったものにしたいですねぇw
- CORBA
- ありましたねぇw
- SOA！
- ソフトウェア高い、使いにくい、認証どうすんだとか、色々手間が
- RPC Protocol
- Protocol Buffer, Thrift, XML-RPC, MessagePack-RPC, ...
社内システム連携: Make it simple!
- 権限の分断を最小限に
- 情報には複数の参照方法を
- ブラウザで見る、APIでやりとりするとか
- UIを作るときは、できれば自身のAPIを呼び出すように作っておくことが望ましい
- モジュール化
- 単機能システムを連携させる
- アップデートが容易な状態を保つ
ということで
社内システムほど他システムとの連携を考えよう。
機能をAPIとして公開しよう。
- APIの互換性さえ保持しておけばバックエンドはいくらでもリプレースできる
- プロトコル、データ構造、意味の一貫性、クライアント要件の不変性/普遍性
Protocol of Closed Web API
- Thrift, Protocol Buffer
- IDL: DSL的なもの
- FTP, RSH, SSH, …
- HTTP
- SOAP, XML-RPC, ...
- JSON
なぜJSONか
- 長期運用が前提
- ドキュメントは風化する
- 一番わかりやすいのは、自分の目で見て確認できること
- YAMLとかXMLとか色々あるけど、個人的にはJSONがみやすい
- 長期運用＝きちんろアップデートするということ
- データ内容の把握
- 人間が目で見てわかりやすいフォーマットが大事
- テストの容易さ
- Curl is great.
百聞は一見にしかず
- 1 time curl >>> 100pages docs
- easy to try >>> performance
- loosely coupled >>> script control
より祖結合で、解釈の自由があるフォーマットは、かっちり決まったプロトコルより、社内システムにおいては重要。
社内システム
- 動くことが大事
- 納期より、まずは動くこと
- 「こんなこともあろうかと」は要らない
- 社内システムなので、必要なものだけでいい。今欲しい必要なものしか作らない。
優先度ハック
- 自分たちのシステムなので、優先度が決められる
- 機能・実装を刻むことができる
- 修正単位を最小化する
逆優先度ハック
- 刻まれた細かい機能追加タスク
- 1つ1つのタスクが刻まれることで優先度をつけやすくなる
- 今いらないなら、あとでやればいい
- 細かい問題に落としておけば、いつでもできるでしょー
- (将来の)要件定義は難しい
- だから後回し
- 社内システムで自分たちが作るからこそ、できること
実装は必要なところから！
開発アーキテクチャ
- アーキテクチャの割り切りが開発と運用を加速させる
- 疎結合に割り切ったアーキテクチャが大事
- 開発・運用の前提が、アーキテクチャをシンプルにする。
- ビジネスへのインパクト
- 社内システムほど試しやすい場所はない。顧客は自分。
