元RX-7乗りの適当な日々 このページをアンテナに追加 RSSフィード Twitter

RX-7(FD3S)WRX STI関連のキーワードで検索されて来られた方へ。
右サイドのカテゴリ『』をクリックすると関連する項目だけが表示されます。
日々の写真は『Flickr』で公開しています。

2014/02/13

デブサミ2014「社内システムの構造と設計、実装のはなし」講演メモ #devsumi


失礼ながら、モリス節炸裂しまくりで面白かった。話上手だなぁ。


「社内システムの構造と設計、実装のはなし」

  • 田籠 聡 氏
    • @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つのタスクが刻まれることで優先度をつけやすくなる
  • 今いらないなら、あとでやればいい
    • 細かい問題に落としておけば、いつでもできるでしょー
  • (将来の)要件定義は難しい
    • だから後回し
    • 社内システムで自分たちが作るからこそ、できること

実装は必要なところから!


開発アーキテクチャ

  • アーキテクチャの割り切りが開発と運用を加速させる
  • 疎結合に割り切ったアーキテクチャが大事
  • 開発・運用の前提が、アーキテクチャをシンプルにする。
  • ビジネスへのインパクト
    • 社内システムほど試しやすい場所はない。顧客は自分。

追記: 資料が公開されました

はてなユーザーのみコメントできます。はてなへログインもしくは新規登録をおこなってください。

トラックバック - http://d.hatena.ne.jp/rx7/20140213/p3

オススメ (一部は、最近読んでいる本とも言う)
Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus) クラウド Amazon EC2/S3のすべて~実践者から学ぶ設計/構築/運用ノウハウ~ [Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ) エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド [24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用 Linux-DB システム構築/運用入門 (DB Magazine SELECTION) キャパシティプランニング ― リソースを最大限に活かすサイト分析・予測・配置 スケーラブルWebサイト 実践ハイパフォーマンスMySQL 第3版 ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) SQLアンチパターン インターネットのカタチ―もろさが織り成す粘り強い世界― ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化 Linuxの教科書―ホントに読んでほしいroot入門講座 (IDGムックシリーズ)

Connection: close