2015/06/27 Remixing つらくないメディア間連携
•Télécharger en tant que PPTX, PDF•
0 j'aime•533 vues
2015/06/27にRemixin With All About,Inc. で発表したスライド。 https://remixing.doorkeeper.jp/events/26208 闇をどうやって攻略していいくかの話です。
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à 2015/06/27 Remixing つらくないメディア間連携
Similaire à 2015/06/27 Remixing つらくないメディア間連携 (20)
2015/06/27 Remixing つらくないメディア間連携
- 2. Remixing 自己紹介 吉田拓実(Yoshida Takumi) @y_takky2014 https://twitter.com/y_takky2014 http://qiita.com/takky 2年間でやってきたこと サーバサイド 各種検証(CMS/MySQL/infinity scroll) 各種フロントアプリケーション→ →社内向けシステム Copyright 2015 All About,inc. 2 API
- 3. Remixing アジェンダ 複数メディアの開発者の悩み 複数メディアを連携した 新機能作成時の悩みと解決法 All AboutのAPI活用事例 API実装時の工夫点 APIを使った今後 Copyright 2015 All About,inc. 3
- 4. Remixing 複数メディアの開発者の悩み Copyright 2015 All About,inc. 4
- 5. Remixing 1.システム構成がバラバラ Copyright 2015 All About,inc. 5 DB フレームワーク 言語
- 6. Remixing メディアB contents hogehoge# hugahuga# img1 link1 プログラムで本文組み立て が必要 Copyright 2015 All About,inc. 6 2.データの持ち方がバラバラ メディアA contents <h1>hogehoge</h1> <h2>hugahuga</h2> testtesttesttest<br> <img src=“test.jpg”> <a href= “allaabout.co.jp> allabout </a> ユーザに表示されるもの がそのまま入っている DBに入っている記事の全文データ
- 7. Remixing つらい Copyright 2015 All About,inc. 7
- 8. Remixing 複数メディアを連携した 新機能作成時の悩みと解決法 Copyright 2015 All About,inc. 8
- 9. Remixing 複雑化する要件 Copyright 2015 All About,inc. 9 エンタメ系のコンテンツを 充実したいから、 メディアA,B,C,Dから エンタメっぽい記事を 新着で集めたものを作って!エンタメ系のコンテンツは、 恋愛/グルメ/ホビーのカテゴリに属 するものでお願いします。 広告記事は無しでよろしく！
- 10. Remixing これらを連携しようと思ったら Copyright 2015 All About,inc. 10 各メディアのDBに 直接接続して 新機能のプログラムで クエリ書いて データ作成しよう
- 11. Remixing 直接DB接続する Copyright 2015 All About,inc. 11 Conncect B; dataB = B.getData(); ~~~~~~~~~~~~~~ サンプルコード 新機能 DBConnect/ getData A B C DConnect A; dataA = A.getData();
- 12. Remixing 直接接続時のデメリット 1つのDBに接続できないとシステムダウン 耐障害性が低い メディア数分DB接続が必要 実装が複雑化 拡張性 影響範囲調査が必要 仕様の把握が難 Copyright 2015 All About,inc. 12
- 13. Remixing Copyright 2015 All About,inc. 13 各メディアのbatchで データを作成して それをmigrationして 持ってこよう
- 14. Remixing Application A batch Batchでデータ作成 Copyright 2015 All About,inc. 14 A NEW Connect/ getData C Connect/ getData Connect/ getData D New Application front Read Application B batch Application D batch Application C batch B Connect/ getData
- 15. Remixing Batchのデメリット 耐障害性は上がる データを前もって準備しておくから メディア数分のbatch実装 再実装が必要なことも 影響範囲の調査は必須 Copyright 2015 All About,inc. 15
- 16. Remixing じゃあ どうしよう? Copyright 2015 All About,inc. 16
- 17. Remixing Copyright 2015 All About,inc. 17 APIを使おう!
- 18. Remixing APIでデータ取得 Copyright 2015 All About,inc. 18 API B D A C DB API Request Get Data Return Data Response Data
- 19. Remixing APIのメリット データの持ち方を知らずに使用可能 データ構造の考慮がいらない。 影響範囲の特定が容易 APIのみの改修でOK 疎結合化 システム間の結びつきが弱くなる 耐障害性UP 拡張性UP Copyright 2015 All About,inc. 19
- 20. Remixing All AboutのAPI活用事例 Copyright 2015 All About,inc. 20
- 21. Remixing API使用した実例 タグページ Copyright 2015 All About,inc. 21 http://allabout.co.jp/taglist/
- 22. Remixing Copyright 2015 All About,inc. 22 http://allabout.co.jp/gm/gc/450229/ 記事に紐づくタグ 記事内容を解析 特徴的なキーワードをタグとして表示
- 24. Remixing SELECT Tag タグページのシステム構成 Copyright 2015 All About,inc. 24 API まとめ Tag 記事 NewsDig DB API Request (Get 記事Data) API Response (記事Data) SELECT 記事Data 記事Data API Request (Get Tag) Tag API Response (Tag)
- 25. Remixing タグページの実装 記事情報を返却するAPIを実装 タグ情報を返却するAPIを実装 メディア間連携する場合はAPI 他メディアの情報をTagのDBに持たない 他メディアには影響されない Copyright 2015 All About,inc. 25
- 26. Remixing API実装時の工夫点 Copyright 2015 All About,inc. 26
- 27. Remixing 返却形式の共通化 JSON形式で返却 Data とMetaから構成 Copyright 2015 AllAbout,inc. 27 data: [ { article_id: 450229, article_title: "40～50代のダイエットは「腕」をチェッ ク！", article_abstract: “40～50代になり「痩せにくい」~", }], meta: { status_code: 200, status_msg: "OK" }
- 28. Remixing ステータスコードの有効活用 HTTPのステータスコードを適切に設定 Copyright 2015 AllAbout,inc. 28 ステータスコード API上の状態 200 OK APIのレスポンスが正しく返却されている 400 Bad Request パラメータが不正 503 Internal Server Error DBや通信が起因で情報取得に失敗
- 29. Remixing ドキュメント化 Qiitaに記載 APIの叩き方や APIの実装ガイドライン共有 Copyright 2015 All About,inc. 29
- 30. Remixing ライブラリ化 APIを叩く部分の実装を共通化 サーバサイド実装者は、 関数呼び出しで使えるように API実装者とサーバサイド実装者が 異なってもスムーズに連携 Composerのような パッケージ管理システムの利用 Copyright 2015 All About,inc. 30
- 32. Remixing APIを使って 解消出来るところ 現在はベタ書き サービスの追加/削除毎に リリース発生 調査・リリースがほとんど を占める API化すると削減 DBにデータ入れ込んで終了 Copyright 2015 All About,inc. 32 調査 47%リリー ス 33% 実装 20%
- 34. Remixing まとめ APIを使うことでシステムを疎結合化 システム間の依存性が少なくなる 改修高速化 使い回しが容易 工夫により実装・利用の容易化 共通仕様の策定 ドキュメント化 ライブラリ化 Copyright 2015 All About,inc. 34
- 35. Remixing Copyright 2015 All About,inc. 35 つらくない！！！
- 36. Remixing ご清聴ありがとうございました Copyright 2015 All About,inc. 36
Notes de l'éditeur
- 今回は2年間やってきたことの中でも、APIを作る・使うことにフォーカスをあてて発表を行いたいと思います。
- 今回の発表は、なぜAPIを使うことになったかということで、 現在の複数メディアの開発者の悩みや、それらのメディアを連携してなにか新しいシステムを作成するときの悩みと解決法を話したいと思います。 次にAll AboutでのAPI活用事例を述べ実装時の工夫点についてお話したいと思います。 最後にAPIを使った今後のシステム構成などを述べます。
- 複数メディアを連携する前に、 複数メディアを開発しているとどんな状況になっているか開発者の悩みから問題点を上げていきたいと思います。
- 弊社に限らず一般的に複数メディアを持っている会社 複数メディアを持っているので、その時の技術のはやりや担当者の好みで使っているシステムの構成がバラバラであるということがあるかと思います。 例えば使っているDBがMySQLだったりSQL Serverだったり PostgresだったりもしかするとRDBではなくMongoDBのようなNoSQLかもしれません。 また、フレームワークレベルでも LaravelやCodeIgniterまたWordPressをフレームワーク代わりに使っているかもしれません。 ただ、この3つのフレームワークはすべてPHPのフレームワークなので、PHPを使えればある程度は読めるかもしれません。 更に、プロジェクトによって RubyだったりPHPだったりJavaだったりと担当者のノリで言語が変わっているかもしれません。 言語やフレームワーク・ミドルウェアが変わる毎にエンジニアの負担は増えていくと思います。
- また、DBの設計自体もその人任せで、バラバラかもしれません。 DBに入っている記事全文データを見ても あるメディアAではHTMLや画像データ/link毎にデータが入っているけど あるメディアBでは記事コンテンツや画像・linkの識別子をデータとして持っておきプログラムで本文組み立てが必要かもしれません。
- このような状況はかなり辛いことになっています。
- そんな辛い状況で複数メディアを連携して新機能を作成するときの悩みと解決法を述べます。
- 例えば要件として ・エンタメ系のコンテンツを充実したいからエンタメっぽい新着記事を集めたものを作って ・エンタメ系の定義は恋愛/グルメ/ホビーに属する ・広告記事は出さないで みたいな要件で複数メディアを組み合わせて新メディアを作ることを考えます。
- その時エンジニアのA君はこう考えるでしょう。 各メディアのDBに直接接続して新機能のプログラムでクエリ書いて直接データを持ってこようと。
- 直接DBに接続する。というのは単一のアプリケーションから複数のメディアのDBに接続して各DB毎にデータを取得する方法です。 サンプルコードは抽象的なものになりますが、Aに接続してAのデータを取得。Bに接続してBのデータを取得というフローがわかるかと思います。
- この方法のデメリットとして 1つのDBに接続できないとすべてのシステムがダウンしてしまうという致命的な欠点があります。 つまり、耐障害性が低いということです。 次にメディア数分データベースの接続が必要となることです。 フレームワークや言語によっては複数DBへの接続の実装が難しいかもしれません。 最後に拡張性の問題が有ります。 どこで何がつながっているかわからないので影響範囲の調査が必要となります。 また、仕様の把握も難しくなってきます。
- なので、エンジニアA君は別の考え方をしました。 各メディアでbatchを作成してほしい形式にしてbatchでデータを取得しようと。
- Batchでデータ作成とはApplicationにあるbatchプログラムでDBAのデータを取得してNew App DBに書き込む形になります。これはApplication B,C,Dでも同様に行います。 その後フロントから新機能を閲覧する際には すでに書き込まれているデータを読みに行くことになります。
- このbatch方式のメリット・デメリットですが 事前にデータを作成しておくので直接DBに接続するよりは耐障害性がアップします。 前もってデータを書き込んでおくので、最新情報は出ませんが、他のDBが落ちても新機能には影響はありません。 しかし、メディアの数だけbatchを実装する必要があります。 また、メディアのデータ構造の仕様が変われば再実装が必要かもしれません。 さらに、直接接続した時と同様に影響範囲の調査が必要で拡張性が低いという欠点があります。
- じゃあこの状態を解決するにはどうすればよいでしょうか
- A君はこう考えました。 APIをつかえばいいじゃん
- APIでデータの取得は 何かのデータをほしいと思った時にAPIに対してリクエストを送ります。 次にAPIがA～Dから必要なデータを取得して返却します。 APIはResponse Dataとして、必要なデータを返却します。一般的にはXMLやJSON形式で返却されます。
- APIを使うメリットとしては3つあります。 1つめは データの持ち方を知らずに使用可能という点です。 使用する人は実際のデータ構造を考慮する必要がありません。 直接接続方式やbatch形式だとデータの取得方法を考える必要がありますが、APIを使う側はその必要がありません。 2つめは影響範囲の特定が容易という点です。 既存メディアに改修があったとしてもAPIのみの改修で済みます。 最後はシステムが疎結合化出来るということです。 各システム間の結びつきが弱くなるので、連携しているメディアが落ちても問題がありません。 耐障害性があがるということです。 また、拡張性も高くなります。影響範囲の調査がいらないので拡張しやすくなります、
- それではAll AboutでのAPI活用事例について見て行きましょう。
- All AboutでAPIをフル活用した事例としてタグページ というもの作成し、今年の2月にリリースしました。
- 記事内容を解析して、特徴的なキーワードをタグとして表示しています。 記事のページでは自分自身に紐づくタグを表示させています。 これをクリックすると
- これはタグページというリスト形式のページに遷移します。 世間一般で言われるタグクラウドのリストですね。 この画面を作成するのに必要な情報は 記事タイトル・記事要約文・執筆者名/写真・サムネイル となっています。 この他メディアからの情報はすべてAPIで取得しています また、色が変わっているアイコンが有るように複数のメディアを連結しています。
- これがタグページのざっくりとしたシステム構成です。 例えば記事のデータがほしいと思った時には APIにRequestを送るとAPIが対象のDBから記事をSELECTし Returnしてくれます。 APIではResponseとして記事Dataを返却することで記事データを取得することができます。 Tagでも同様のステップを踏み情報を取得できます。
- タグページでは記事情報を返却するAPIとタグ情報を返却するAPIを別に実装しました。 メディア間の連携する部分に関してはAPIを使っています。 他メディアの情報をTagのDbに持たないため、他メディアのことを考える必要がありません。 そのため、他メディアには影響されません。
- それでは、実際にAPIを実装するときに工夫した点を述べたいと思います。
- まずは標準的な形式で返却するということです。 一般的にAPIで使用されるJson形式で返却しました。 AllaboutのAPIではAPIのステータスが判別しやすいように dataに加えてステータス等のmeta情報も返却しています・
- 2つめはステータスコードを有効活用するということです。 AllaboutではAPIの状態に応じてステータスコードを適切に設計しています。 基本的にはHTTPのステータスコードに準拠していますが 例えば200 OKはAPIレスポンスがただし返却されている状態 400 Bad Requestはパラメータが不正な状態など規定しいています。
- ただ、規定しただけでは、実装者毎に際が出てしまいます。 そこで、Qiitaに記載しAPIの叩き方やAPIの実装ガイドラインを共有しています。 これにより、実装者が変わっても共通の形式でAPIが実装できます。
- 最後にライブラリ化があります。 APIへのアクセス部分の実装を共通化し、サーバサイド実装者が異なっても関数の呼び出しのように使えるようにしました。 これによりAPI実装者とサーバサイド実装者が 異なってもスムーズに連携ができています。 また、Composerのようなパッケージ管理システムを使用することでライブラリの導入自体を容易にしています。
- 最後にAPIを使った今後について述べたいと思います
- 左図は弊社のSP版サイトになります。現在はHTMLにサービスリストをベタ書きしているのでサービスの追加や削除毎にリリースが発生しています。 調査リリースが工数の8割を占めています。 これをAPI化するとDBへのデータ投入で終了するため工数がかなり削減できます。。
- 加えてサービスで使うものをすべてAPI化する。というのも考えられます。 各メディアで新着や ランキングといったデータをAPIで取得することによって新しくサービスを作るときに使い回しが可能になります。
- 最後に今回の発表をまとめます。 APIを各メディア間の連結に使うことでシステムを疎結合化することが出来ます。 システム間の依存が少なくなります。 システム間の依存が少ないため影響範囲が小さく改修が高速化できます。 また、共通の形式のため使い回しが容易になります。 ただ、APIを実装・利用するだけでは、最大限に効果が発揮できないので工夫が必要です。 例えば共通仕様を策定して、利用・実装をだれでも出来るようにする。ですとか ドキュメントとして残すことで後から仕様の確認が出来ます。 さらにライブラリとして実装することで利用も簡単になります。
- デメリット:複数API組み合わせるとAPIの問題なのかアプリケーションの問題なのかの切り分けが難しくなる 速度は遅くなる 通信量が増える