Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Django with AWS native services.

Django with AWS native services.

Django AWS native なサービスとして開発する

Kosei Kitahara

January 12, 2018
Tweet

More Decks by Kosei Kitahara

Other Decks in Technology

Transcript

  1. Django with AWS native services Django を AWS native なサー

    ビスとして開発する By Kosei Kitahara (@Surgo)
  2. アプリケー ション構成 主に以下の2 つの WebApp からなる Track: エンドユー ザー の環境、

    行動情報を収集 (High latency) Report: 環境や行動情報の可視化 (Low latency) 主に以下の2 つの Worker キュー からなる Aggregate: Track の情報を Report で参照可能なデー タ形式へ 変換 (High Latency) Screenshot: スクリー ンショットの取得など (Low latency)
  3. 利用している AWS Native Service ( 抜粋) Application Load balancer ECS

    (with Application Auto Scaling) Aurora (Auto Scaling for Replicas) ElastiCache DynamoDB (Auto Scaling) SQS (Auto scaling) Redshift with Kinesis Firehose (Auto scaling)
  4. テクノロジー 選定基準 Auto Scaling!!1 Maintenance free (managed & auto upgrade)

    Work locally Work with Django native (none customized) apps django‑rest‑framework django‑registration‑redux django‑storages etc...
  5. Aurora/Redshift 最初からシャー ディングにより書き込みを分散 まだ Aurora Multi‑Master がプレビュー なので Redshift の同時クエリー

    実行数制限 https://github.com/uncovertruth/django‑horizon/ Django のデー タベー スバックエンド Aurora: 標準の MySQL ( ちょっとカスタマイズ) Redshift: https://github.com/shimizukawa/django‑redshift‑ backend Redshift 用にクエリー をチュー ニング ( 主に DISTKEY) https://github.com/onysos/django‑composite‑foreignkey
  6. ElastiCache しょうがないけど Auto Scaling がない Auto discovery 対応のバックエンドを利用 https://github.com/uncovertruth/django‑elastipymemcache Double

    write & Double read Maintenance 時間をずらした2 クラスター で双方自動更新 カジュアルに再起動 ( しないけど) そのうち DAX に移行したい
  7. DynamoDB Amazing! (Performance, cost, maintenace free) Object Mapper https://github.com/pynamodb/PynamoDB For

    local dev & testing https://github.com/spulec/moto Factory‑boy なども _ b u i l d をカスタマイズしそのまま利用 そのうち DAX & Global region へ以降する
  8. Kinesis Firehose django form や django‑rest‑framework serializer の validation ‑>

    save 機構をカスタマイズするのみ local なら直接 sqlite へ、 本番なら firehose 経由で Redshift へ という用に切り分け https://github.com/spulec/moto を利用し、 想定する API へのリク エストと引数をテストしている 現在テスト稼働で 600Krecords/hour/shard を挿入
  9. Lesson learned Auto scaling さまさま ( 常時監視対象が大幅に減る) APM が重要 Auto

    scaling しないものは自前でなんとかする Django の枠をなるべくはみ出ない Aurora と DynamoDB は世界を救う
  10. Future tasks boto の https リクエストのオー バー ヘッドが高い DynamoDB は

    DAX を利用する SQS や DynamoDB のオー トスケー ルが追いつかない ( スパイク) スケジュー ルで頑張るのと母数を増やす ( みんな頑張って~)