プロダクト開発を支える技術

2015年6月10日 | 瀬尾 昭光

こんにちは!エンジニアの瀬尾です。
今回は私達がどのようなやり方でプロタクトを開発しているのか
実際のリアルタイム解析基盤サービスのアーキテクチャを交えて紹介します。

構成図

スライト?1

今回のインフラはすべてAWSのサービスを利用して構築しました。
IaaSとマネージドなサービスの組み合わせにより開発・運用コストを削減しています。
各レイヤやサービス構成は

management

  • UI:S3 + CloudFront
  • Job:SQS
  • ストレージ:RDS(MySQL)

サービス利用者の管理画面レイヤです。

UIはAngulerJSのSPAがS3に配備されていて、CloudFrontにより配信されています。
Rename Distributionパターンによってエッジサーバーのキャッシュタイムアウトにかかわらずデプロイ時に最新のUIが配信される仕組みになってます。
UI背後のアプリケーションおよびJob(SQS Worker)はRuby on Railsアプリケーションで、利用者の情報などをRDSに格納しています。

context aware services

  • トラッキング:S3 + CloudFront
  • データ処理:Kinesis + KCL(Java)
  • ストレージ:S3 + DynamoDB + Dynamic DynamoDB

Audienceデータをリアルタイムに収集・処理するサービスです。
S3に配備された収集タグ(JavaScript)がCloudFrontによって配信されています。
収集されたデータは全てKinesisのStreamにput recordされていて、StreamのデータをConsumerが並行処理で用途に応じた加工を施してストレージに格納しています。
Streamに全てのデータを1回入力しているので、用途に応じて機能ではなく、アプリケーションを追加していくAgilityが高い拡張が可能になってます。
また、DynamoDBはDynamic DynamoDBを用いることによってリクエストの増減に自動で対応しています。
Dynamic DynamoDBは、AutoScalingを用いたSelf Healな構成です。

banshee

OAuth2.0による認証を行うサービスです。
ELB + WEB + RDS(MySQL)の構成です。

モニタリング

モニタリングに問わずSaasのサービスを選択することが多いです。
各種アラートは全てHipChatに集約されています。

マイクロサービス(Microservices)

モノリシックではなく、複数の軽量なサービスによって連携されたアーキテクチャによるアプローチを採用しています。
構成図には記載してませんが、メール配信などの自社サービスともAPIで連携されてます。

各サービスはHTTP API経由で呼び出しされており、データ管理も言語もサービスごとで統合されてません。
HTTP APIはREST LEVEL3の設計レベルを採用していて、利用する言語ごとにSDKを提供しています。
また、サービス毎に独立した開発・デプロイサイクルを確立しているので、各サービス毎にビルドパイプラインが構築されていて継続的デリバリを実現しています。

basic-pipeline

チーム構成

エンジニアは1つの部署に所属していますが、サービス毎に複数の役割が混在したチームで構成されています(コンウェイの法則)。
エンジニアのナレッジ共有や継続的なワークフロー改善・自動化などをミッションとするチームも存在します。

まとめ

今回は簡単にですが私達がどのようにプロダクトを開発しているのか、紹介させて頂きました。
マネージドなサービスやマイクロサービスといったアプローチを積極的に推進することによって、良いプロダクトを生み出すというモチベーションにフォーカスできるよう考えています。
なお、e-Agencyでは私達と一緒にプロダクト開発を推進していく仲間を募集しています。
このエントリを読んで少しでもご興味をお持ちいただけた方は、ぜひともご応募ください!

ライター

お問い合わせ

サービスに関するご相談は
こちらよりお気軽にお問い合わせください。

関連記事

e-Agencyの様々な情報をFacebookでお届けします!