Treasure Data Serviceの機能開発と安定運用の狭間におけるあれこれ #tdtech

• 機能開発側のはなし
• システムアーキテクチャのはなし
• いまどんなところに注力しているか
• 信頼性確保

アーキ

• (API server w/ RoR) * 4 w/ load balancer
• MySQL(JobQueue)/S3/RiakCS/MySQL(AccountDB)
• Worker(Ruby+Java)
• YARN Cluster(Hive/HDFS) / Presto Cluster(presto)
• ObjectStorage(S3/RiakCS) MetadataDB(PostgreSQL)
• Log Collector(fluentd)
• embulk
• Hosted cevent collector(fluentd)
• digdag

チーム構成

• hadoopやってるチーム
• JSでコンソール書いてるチーム
• APIサーバーの開発をやっているチーム
• キューの管理をやっているチーム
• インフラの管理をやっているチーム
• 1チーム2-4名 プラス 外部のひと 計6人
• エンジニア24人 マネージャー3人 その他サポート、セールスなど
• Scalaのほうが好きな人はScala書いてもらうし、Rubyが好きな人はRubyを書く

SRE

• ソフトウェアエンジニアとは別のSRE
  • Site Reliability Engineering
  • 信頼性
  • SRE専用のチームはTDにはない
• ストレージの開発
• 新機能開発
• 何割かの時間を信頼性の確保に当てる

Site Reliability Engineering: How Google Runs Production Systems

• 分散システムを安定させる
• ローンチで失敗しないために設計の段階から考える

• 信頼性確保のためのしごと

• Product/Development/CapacityPlanning/Testing ReleaseProcedures/Postmortem RootCauseAnalysis/IncidentResponse/Monitoring

• JIRA/Github/CircleCI

• Datadog
• CircleCI/Github/Chef
• JIRA/Gyazo
• PagerDuty/StatusPage/Sentry/Confluence

• Slack/Datadog/CloudWatch/NewRelic/Pingdom

• APIに依存しているコンポーネントが多く密結合

• CircleCIがGreenになったらリリース
• capacity palnning
  • 予測モデルを作って、先行してノードを作ったりプロビジョニングしたりして、顧客のリソース不足を防ぐ
  • リトライなどを適切な方法で適切な回数行う − datadogは課金がインスタンスごとで、簡単にメトリクスを増やせる
• アーキを直したければプロダクトを直す必要があるので、チーム間でのコミュニケーションが必要
• JIRA/Confluenceを利用して、クリアに書く (オープンかつ簡潔に、分かるように書く)
• US/JP待ちだと時差のオーバーヘッドが発生する
• 遠隔地
• LucidChart(Webベース)
• Numbers(ローカルで動かせる)

• digdag/prestoそれぞれのチームでdatadogのダッシュボードがある

• 開発をしながら信頼性確保するためには何をしたらいいかの人材が必要

• 超エースエンジニアを信頼性確保にかかずらわせるのはよくない

• metricsを集めて自動化するなどしたい
• 信頼性確保のためのヒアリングを行う