More Related Content Similar to 2015/06/27 Remixing つらくないメディア間連携 (20) 2015/06/27 Remixing つらくないメディア間連携9. Remixing 複雑化する要件
Copyright 2015 All About,inc. 9
エンタメ系のコンテンツを
充実したいから、
メディアA,B,C,Dから
エンタメっぽい記事を
新着で集めたものを作って!エンタメ系のコンテンツは、
恋愛/グルメ/ホビーのカテゴリに属
するものでお願いします。
広告記事は無しでよろしく!
Editor's Notes
今回は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の問題なのかアプリケーションの問題なのかの切り分けが難しくなる
速度は遅くなる
通信量が増える