Kubernetesの大規模で成功したユーザーに関する一連の記事では、オーディオコンテンツの配信用の人気のあるオンラインサービスであるSoundCloudに関する話を続けています。 昨年、Spotify ABはこの会社（SoundCloudのようなスウェーデンのルーツを持つ） 、そして最近では中国のインターネット大手のTencentを買収する予定でした。 毎月1億7500万人のアクティブユーザーにサービスを提供しているにも関わらず、SoundCloudは最近、昨年夏に大幅な減員（173人の従業員）により知られるようになった財政問題に直面しています。 いずれにせよ、私たちはこの問題の技術的な側面、またはむしろKubernetesのアプリケーションにはるかに興味を持っています。これが公的な情報源からのSoundCloudについて知られていることです...
Kubernetesへの移行を開始
2015年11月にサンフランシスコで開催された最初の年次Kubernetesカンファレンス-KubeCon 2015では、SoundCloudエンジニアのTobias Schmidtがマイクロサービスアーキテクチャへの会社の進路について話しました（2014年までに起こりました） 。
SoundCloudは、Ruby on Rails（+ MySQL、+ RabbitMQ）上のモノリシックアプリケーション （「4〜5年前」）で始まりました。これは、CapistranoとChefを使用して展開され、インフラストラクチャを記述しました。 その当時の主な問題の中には、スケーリングの遅さ、展開スキームの痛みと不安定性、新しいアプリケーションの時間のかかる展開がありました。 これらの理由から、同社は独自のシステム、「Herokuスタイルのパオク」と呼ばれるバズーカを作成しました。 コンテナを（LXCに基づいて）管理することにより、開発者にアプリケーションをデプロイしてスケーリングするための簡単なコマンドを提供しました。 当時、同社には400〜500のサービスがあり（すべてが本番ではなかった）、バズーカを使用すると、アプリケーションリリースの迅速なロールアウトとロールバック、それらのスケーリング、チームの独立性の問題を解決できました（開発者は運用の専門家に連絡する必要がなくなりました）新しいリソースを取得します）。
これらの実験中に、SoundCloudの専門家はGoコンテナと言語に夢中になりました 。 同時に、内部的に作成されたバズーカは、単純なHTTPリクエストハンドラーから複雑でリソースを要求するアプリケーションに変換された大幅に拡張されたマイクロサービスとの連携に適さなくなりました（これらは既にScala、Clojure、JRubyで記述されています）。 さらに、バズーカの維持と開発は会社の利用可能なリソースでさらに難しくなり、コンテナの世界ではDockerが注目を集めました（そしてSoundCloudの開発者はそれに夢中になり、CI / CDで使用し始めました）。 これらすべてにより、エンジニアはオーケストレーションのためにある種のサードパーティシステムに切り替えることにしました。
Kubernetesを選ぶ理由
SoundCloudは、Kubernetesを「ネイティブ」のバズーカおよびMesosのような世界で利用可能な他のDevOps製品と比較し、このシステムの機能を現在の要件と比較しました。 Kubernetesの選択は、次の理由によりレポートで説明されています。
- ユーザー/開発者が作業するのに十分なシンプルで理解可能な基本オブジェクト：コンテナー、ポッド、サービス、 レプリケーションコントローラー 。
- 強力なネットワーク機能：ネットワークレベルで異なるトラフィックとリソースを持つ異なるアプリケーションの柔軟な構成、ユーザー接続の便利な監査、安全なトラフィック分散。
- 炉床レベルの計画。共通のライフサイクルで接続されたさまざまなコンテナを配置できます。
- リソースをグループ化するためのラベルのシステム、それらの検出およびそれらに対する制限の設定。
- 大規模で活気のあるコミュニティ、および商用サポートの利用可能性。
- SoundCloudエンジニアの理解において、Kubernetesプロジェクトは基本的にバズーカに投入されたアイデアを拡張しました。
結論：2015年末現在、SoundCloudは、Google Cloud Platformの一部およびデータセンター内のベアメタルクラスターとしてKubernetesを積極的に実験していました。 当時の当面の計画は、CIパイプラインの完成（「基本的に構成」されていた間）、モニタリングのためのPrometheusとの完全な統合、およびロギングの問題の解決でした。 これらの計画で言及されているプロメテウスとの物語は、特別な注目に値します...
プロメテウス
今日Kubernetesで作業しているエンジニアがプロメテウスについて聞いたことがないことはまずありません。結局、これは正式にK8自体の後ろに立っているCNCF（Clound Native Computing Foundation）組織の最初のプロジェクトの 1つです。 これまで、このオープンソースプロジェクトは「システムとサービスの監視システム」として位置付けられ、指定された時間間隔で指定されたデバイスからメトリックを収集し、それらにルールを適用し、結果を示し、指定された値の特定の条件が満たされた場合にトリガーします。 Prometheusの主要なコンポーネントはGoで記述されており、現在の一般的なアーキテクチャは次のようになっています（図はドキュメントから引用されています ） 。
SoundCloudとKubernetesに関する記事でこのCNCFプロジェクトに特別な注意が払われているのはなぜですか？ 実際、この会社は最初の開発に携わっており、これは2012年に発生しました。SoundCloudエンジニアがKubernetesへの切り替えについて理論的に考えることができるようになるずっと前からです（当時は存在しませんでした） 。 時間が経つにつれて、プロメテウスアプリケーションの人気により、彼はより広範なコミュニティでサポートされる独立したプロジェクトになり、2016年にCNCFランクに加わり、組織の2番目の（Kubernetes）プロジェクトになりました。
さらに興味深いことに、元Googleの従業員であるマットプラウドは、SoundCloudのプロメテウスの後ろに立っています。 2012年までに、SoundCloudは統計および監視に使用されるユーティリティ（StatsDおよびGraphite）に不満を抱き、代替手段を探し始めました。 当時入社したGoogleのエンジニアは、時系列などのデータを多次元形式で保存し、簡単なクエリ言語を使用して選択できる適切なオープンソース製品を見つけることができませんでした。 そして、プロメテウスプロジェクトを開始し、「彼（マットプラウド）がBorgmonについて知っていたことに触発されました -クラスターマネージャーとタスクスケジューラBorg（誰もが知っているように、Kubernetesの祖先になった）の仲間です。」
その結果、Matt ProudはSoundCloudにわずか2年間入社しました（2013年の終わりに会社を去り、2014年にGoogleに戻りました） 。プロメテウスの作成を開始しました。 すでに2012年にこのプロジェクトはGitHubで公開され 、1年後にSoundCloud自体のプロダクションで使用されるようになりました。
「プロメテウスは、Kubernetesが存在する前に書かれたものと、さまざまな種類のアプリケーションを監視する必要がある世界のために書かれたものの良い例です。 PrometheusはKubernetesのアプリケーションを監視するだけでなく、Mesos、Docker、OpenStack、その他のプラットフォームも監視します。 さらに多くが表示されるだけであり、個人的には、より多くの主要なプラットフォームがあると確信しています。 ですから、これは本当にユビキタスで強力なツールです。 単一のケースではなく、さまざまなユースケースに適した優れたツールを選択しようとします。 それらは必ずしもコンテナではありません-仮想マシンがあるかもしれません。」
-2016年にCNCF技術委員会の委員長であり、Weaveworksの責任者であるAlexis Richardsonは、プロメテウスがCNCFでインキュベーションプロジェクトの公式ステータスを取得したとき。
SoundCloudでの制作
SoundCloudのプロダクションエンジニアリングチームのリーダーであるBjörnRabensteinによる2016年4月のインタビューによると、同社はすでにプロメテウスとKubernetesをプロダクションで使用しており、これらの製品はインフラストラクチャニーズを解決する優れた組み合わせと呼ばれています。
このインタビューで明らかになったように、バズーカの代替品を選択したとき、Kubernetesの勝利は「他の決定よりも少し先に」起こりました。その理由は、プロジェクトの相対的な若さでした。
2016年のヨーロッパのDevOpsイベント（ ロンドンのJAX DevOps、 ベルリンのCoreOS Fest、ベルリンの DevOpsCon 2015 ）で、Björnは、Prometheusの主要な開発者の1人で、以前SoundCloudで働いていたCoreOSのエンジニアであるFabian Reinartzと共演しましたPrometheusでKubernetesを監視する：
このレポートで説明された経験は、すでにSoundCloudの実稼働環境に基づいており、2016年11月にContainerDays NYC 2016で同じTobias Schmidtエンジニアによるパフォーマンスによってすぐに補足されました。 （レポートで説明されているKubernetesのPrometheus構成の例に興味がある人は、GitHubの特別なリポジトリで見つけることができます。）
残念ながら、SoundCloudインフラストラクチャ自体の詳細はほとんどありません。 ただし、著者によると、実際のインフラストラクチャから取得したスクリーンショットがあります。 特に、その上で、着信リクエスト（HTTP + Thrift）からのRPSに対して19000のインジケーターを見ることができます：
SoundCloudの欠員からプロダクションエンジニアのポジションまで、「Kubernetes、Kafka、Distributed Storage、Prometheusなどのテクノロジーがインフラストラクチャに関与している」こと、そしてバックエンドエンジニアのポジションから、会社はまだScala、Java、Go言語をバックエンドに使用していること、 SparkおよびHadoopテクノロジーと同様に。 （ちなみに、SoundCloud実稼働インフラストラクチャでのGoの使用については別の記事がありますが、ほとんどの場合、すでに部分的に古くなっています。）
最後に、SoundCloudの生産インフラでは次のことがわかっています。
- マイクロサービスは、 「アクティブな並列処理でサーバーを作成するために使用されるJVM用の拡張可能なRPCシステム」としてTwitterで開発された Finagleオープンソースフレームワークを使用します。
- データの一部はmemcached、RedisおよびMySQLに保存されます。
- AWSクラウドサービス（S3およびGlacier） は 、ペタバイト単位で測定されたデータの保存、およびトランスコーディング（Amazon EC2）およびユーザー行動の分析（Amazon Redshift）に使用されます。
- Elasticsearch は、多数のユーザーの検索クエリをリアルタイムで提供します。
- IPVS（L4）およびHAProxy（L7）は負荷分散に使用され、Consulはサービス検出に使用されます。
Kubernetesの運用機能とSoundCloudのプロダクション環境の具体的な数値は公表されていませんが（おそらく、同社のエンジニアがPrometheusの監視ツールの普及に関与しているため）、その使用の事実は明らかであるだけでなく、オンラインでもありますKubernetesの真に大規模なプロダクションにおける初期ユーザーの1人。
サイクルからの他の記事
- 「 Kubernetesの生産における成功事例。 パート1： eBayの4,200の囲炉裏とTessMaster 」
- 「 Kubernetesの生産における成功事例。 パート2： ConcurとSAP 。」
- 「 Kubernetesの生産における成功事例。 パート3： GitHub 。」
- 「 Kubernetesの生産における成功事例。 パート5： Monzo Digital Bank。 」
- 「 Kubernetesの生産における成功事例。 パート6： BlaBlaCar 。」
- 「 Kubernetesの生産における成功事例。 パート7： BlackRock 。」
- 「 Kubernetesの生産における成功事例。 パート8： Huawei 。」
- 「 Kubernetesの生産における成功事例。 パート9： CERNおよび210 K8sクラスター。
- 「 Kubernetesの生産における成功事例。 パート10： Reddit 。」