生産におけるKubernetesの成功事例。 パート10：Reddit

先週、すべての新しいRedditサービスがKubernetesクラスターに基づいたインフラストラクチャ上で実稼働で開始されることが発表されました。 これは、最も人気のあるオンラインリソースの1つであるK8への移行パスに関する重要なマイルストーンです。







Likbez ： Alexaによると、これまでのところRedditは世界のトップ20サイト（米国では6位）に入っています。 このアメリカ出身のオンラインコミュニティは、4億人以上のアクティブな（1か月以内の）ユーザー、1200万の出版物、および1日あたり20億票で構成されています。



Redditエンジニアが昨年12月にKubeCon 2018でKubernetesに来た理由と方法について（ プレゼンテーション + ビデオ ）プロジェクトエンジニアリングのリリースエンジニアリンググループ、インフラストラクチャ部門の長であるGreg Taylor

なぜKubernetesに来たのですか？

2016年の初め、 モノリシックアプリケーションとして実装されたサービスには、約20人のエンジニアが3つのチームを形成し、そのうちの1人はストーリーのヒーローであるインフラストラクチャチームでした。 しかし、今年は大きな変化をもたらしました。今年の終わりまでに、60人以上のエンジニアが会社で働いていました（そして2018年の終わりまでに、彼らの数は200人に増加しました。つまり、わずか3年で、スタッフの10倍の増加が観察されました ）。



そのような急速な成長率は、モノリシックアプリケーションアーキテクチャの無関係性（非効率性）をアジェンダに置いています。なぜなら、さまざまなコンポーネントに（異なるチームによって）多数の変更を加えることが非常に困難になったためです。 問題を解決するために集まって多くのオプションを検討したエンジニアは、 サービス指向アーキテクチャ（SOA）の道を選びました。



大きなモノリスの代わりにサービスアーキテクチャに切り替えると、Redditは新しい問題にぶつかりました。 インフラストラクチャチームは 、サービスの初期化中、継続操作中、デバッグ中およびパフォーマンス問題の解決中など、さまざまな段階で非常に依存していることが判明した開発者の活動のボトルネックになりました 。 問題の迅速な解決策として、会社は「インフラストラクチャ指向」と呼ばれる自給自足のチームを形成しました。そのようなチームの参加者は、インフラストラクチャの運用分野で必要なスキルを備えていたため、インフラストラクチャチームのアクションを待たずに多くの困難を克服することができました。



しかし、それはまだ一時的な解決策であり、実践により、誰もがサービスのためにスタック全体を操作したいわけではないことが示されました。







この状況はどのように解決されましたか？ 組織は、 サービス所有者の概念を導入しました。 サービス所有者は 、サービスを最初から最後まで開発し、サービスを早期に頻繁に展開し、サービスを運用できます（可用性とパフォーマンスの問題を含む）。 しかし、これを達成する方法は？



非の打ち所のないスキルを持つエンジニアのチームが、知識のない多くのレンガのサービスを組み合わせることを期待する代わりに、最小限のテクノロジーに影響を与える、サービスを生産にもたらすための綿密な事前定義されたパスを提供する必要があります。 これにより、エンジニアが多くの新しい技術やツールを学ぶ必要がなくなります。

「このアイデアを実践するためには、知識、プロセス、ベストプラクティスなどをよりアクセスしやすい形式に「詰め込む」必要がありました。」

InfreRedd-RedditのKubernetes

これが、KubernetesをベースにしたRedditの内部インフラストラクチャ製品であるInfreReddの登場です。



定義で指定されたサービス所有者の3つのニーズはどのように満たされましたか？

1.開発

組織での開発の標準は、特定の言語またはフレームワークの選択を示すものではなく、対応するサービスの一般的な「形式」を設定します。 標準—プログラミング言語に依存しないサービス仕様 —には、RPCプロトコルの定義、秘密の操作、メトリックの返却、トレーサビリティ、およびログ発行の形式が含まれます。 Pythonでのこのような仕様の実装例は、 ベースプレートプロジェクトで見つけることができますが、実際の使用に役立つとは思われませんが、インスピレーションになる可能性があります。



さらに、新しいサービスを作成する際のクイックスタートのために、さまざまな言語（Python、Go、Node）のコードスタブ、Dockerfile、CIの構成、ヘルムチャートなどのマテリアルが作成されました。



ローカル開発を支援するために、Redditエンジニアの選択はGoogleの製品Skaffoldに委ねられました 。これは、開発者にリードスルーサイクル編集→再構築→更新を提供します。

• Kubernetesの詳細な知識は必要ありません。
• 可能な限り生産に近い。
• 標準のチャート/画像を使用できます。
• および-以前使用されていたMinikubeとは異なり、Skaffoldでの作業には 、稼働中のラップトップからの膨大なリソースは必要ありません （ロールアウトはリモートクラスターに対して行われるため）。

2.デプロイする

Redditは継続的配信プラットフォームDroneを使用してテストを実行し、アーティファクト（通常はDockerイメージ）を構築します。



KubernetesはもともとDroneのHelmプラグインを展開に使用していましたが、エンジニアはすぐに「作成または更新されたオブジェクトの状態をよりよく理解する」システムが必要であり、展開プロセスのさらなる自動化につながるため、Helmはそれに満足していないという結論に達しました使用するツールにアピールし、障害やパフォーマンスの問題が発生した場合にロールバックを一時停止できるソリューションの必要性。



その結果、 SpinnakerはKubernetesでの展開を調整するために選ばれました。 彼のために、テンプレートは典型的なパイプライン用に作成されました（Jsonnet上）。 次に、Helmチャートが生成されます。これは、 Spinnaker の取り組みにより Kubernetesに既に展開されています。 ユーザーは、展開の進行状況に関する情報を受け取り、問題が発生した場合の診断に役立ちます。 ステージング/プロダクションでの一般的な展開プロセスは、非常に一般的な方法です。

3.操作

まず、サービス所有者とインフラストラクチャチームの義務はどのように共有されますか？

• サービス所有者 ：Kubernetesの基本を理解し、 サービスを展開して運用します。
• インフラストラクチャチーム ：Kubernetesクラスターの操作性（ロールアウト、サポート、スケーリング）を維持し、必要なすべてのリソースを提供し、信頼性が高く生産的なフォールトトレラントサービスの設計について組織のエンジニアにアドバイスします（特に、トレーニングセッションが定期的に開催され、その記録が配布されます）会社全体）。

サービス所有者の権利は制限されています。 ただし、（問題を診断するために）本番環境にアクセスするために、ネームスペースへの完全な権限を与える一時トークンを（特別なコンソールユーティリティを介して）要求することができます。



動作の別の重要なポイントは、さまざまなソースから生じる可能性のある潜在的な損傷の最小化です。 Redditがこれに対して行うことは次のとおりです。







操作に携わるエンジニアの生活を楽にするために、次のことも含まれます。

• Wavefront-メトリック用。
• PagerDuty-アラート用。
• Zipkin-トレース用。
• Sentry-例外とエラーを追跡します。
• 集中ログシステム。

RedditのKubernetesステータス

昨年12月の時点でのKubernetesインフラストラクチャに関する一般的な統計は次のとおりです。

• 7個のクラスター（3〜6個の新しいクラスターは、今後数か月以内に追加される予定でした）。
• すべてのエンジニアリングチームの3分の1から半分がKubernetesと対話します。
• 約20のRedditサービスがK8で運用されています。
• 営業日に、これらのサービスのK8への10〜20の展開が行われます。

組織全体でのKubernetesでのInfreReddの可用性は2019年の第1四半期に計画されていたため、Kubernetesが提供する運用環境での新しいサービスの展開が暗示されました。 （当時、これは4つの新しいサービスのうち約3つで発生していました。）



記事の冒頭で述べたように、このマイルストーンは先週成功しました。

サイクルからの他の記事

• 「 Kubernetesの生産における成功事例。 パート1： eBayの4,200の囲炉裏とTessMaster 」
• 「 Kubernetesの生産における成功事例。 パート2： ConcurとSAP 。」
• 「 Kubernetesの生産における成功事例。 パート3： GitHub 。」
• 「 Kubernetesの生産における成功事例。 パート4： SoundCloud（著者Prometheus） 。
• 「 Kubernetesの生産における成功事例。 パート5： Monzo Digital Bank。 」
• 「 Kubernetesの生産における成功事例。 パート6： BlaBlaCar 。」
• 「 Kubernetesの生産における成功事例。 パート7： BlackRock 。」
• 「 Kubernetesの生産における成功事例。 パート8： Huawei 。」
• 「 Kubernetesの生産における成功事例。 パート9： CERNおよび210 K8sクラスター。