手頃な価格のサービスとしてKubernetesを使用したインフラストラクチャ

Kubernetesは、プロジェクトのフォールトトレランス、スケーラビリティ、および品質サービスの厳しい要件を満たすことを完全に可能にするテクノロジになりました。 今日、K8は大規模な組織やプロジェクトでより一般的であるという事実にもかかわらず、小さなアプリケーションに適用することを学びました。 ほぼすべてのクライアントに見られるすべてのコンポーネントの統一と一般化により、メンテナンスのコストを削減することが可能になりました。 この記事では、ビジネスニーズとその技術的な実装から得られた経験を紹介します。これにより、手頃な価格で高品質のソリューションとサポートを提供できます。

標準としてのロケット科学

まず、これにどのように到達したかについての一般的な言葉から始め、以下に提案するインフラストラクチャの技術的な詳細の概要を読みます。



公式の約10年間、FlantはGNU / Linuxおよび無数の関連技術とソフトウェアのシステム管理に携わってきました。 この間ずっと、作業プロセスを改善しました。多くの場合、会社を手作業（多くの単調な問題が発生したときに「手動で」サーバーに行く必要がある）から生産をストリームする（通常の構成、集中管理、自動展開など） 工場と比較しました 。）。 私たちがサービスを提供するプロジェクトの多くは非常に異なっていますが（適用された技術のスタック、パフォーマンス、スケーリング要件など）、それらは体系化する必要のある基盤を持っています。 この事実により、高品質のサービスを標準的なサービスに変えることができ、リーズナブルな価格で追加のメリットを顧客に提供できます。



さまざまなプロジェクトの経験に基づいて社内のベストプラクティスを拡大し、それらを要約し、場合によっては「プログラミング」して、これらの結果を他の利用可能なインストールに拡張します。 以前は、構成管理システム（Chefを推奨）がこのための重要なツールでした。 インフラストラクチャに徐々にDockerコンテナを導入し、それらの設定をChef機能と統合するための論理的な一歩を踏み出しました（これをdappツールの一部として実装しました）...



しかし、Kubernetesの出現により、多くのことが変わりました。 次に、Kubernetesの構成について説明し、以下のインフラストラクチャを取得します（顧客に提供します） 。

• 一元管理
• すぐに向きを変える
• 新しいサービスによって簡単に補完され、
• リソースプロバイダー（クラウドプロバイダー、データセンター）に依存せず、
• プロジェクトの複雑さやワークロードの増加の場合に拡張可能、
• 継続的な統合とアプリケーション配信（CI / CD）のために、最新のプロセスとテクノロジーと簡単に統合します。

このインフラストラクチャへのアプローチは、最高のソリューション、無数の試行錯誤、およびITシステムのサービスにおける真に多面的な経験を継続的に検索した結果です。 これは、さまざまな規模のプロジェクトに対する合理的な「規範」の現在のビジョンです。



その後、ビジネスオーナーに頻繁に生じる感覚：「それはクールに聞こえますが、それはある種のロケット科学であり、複雑すぎて高価であるため、私たちにとってはそうではありません。」 しかし、私たちの経験では、この「ロケット科学」は、Kubernetesの実装については「そのレベルではない」と考える人にとっても理想的であることが示されています。

1. 利点は、機能するだけでなく、事故が発生した場合に修理され、徐々に（要求に応じて）改善されるインフラストラクチャです...これは、その「性質」により、耐障害性、スケーラビリティ、開発サポート（テストループ、展開、CI）のすべてのニーズをカバーするインフラストラクチャです/ CD）。 DevOpsのベストプラクティスと業界標準のオープンソースコンポーネントに基づいています。
2. 複雑さは私たちの責任の領域であり、逆に、ユーザーにとって結果を可能な限り単純にすること、つまり 開発者。
3. コスト -小規模プロジェクトのこのような典型的なインフラストラクチャを保守するための通常の月額サブスクリプション料金は80〜120千ルーブルで、これは「条件付き平均」Linuxエンジニアを雇うことに匹敵します。

小さなプロジェクトが意味することとそのニーズは、次の段落で説明します。次の段落から、典型的なインフラストラクチャの構造についての話が始まります。

技術的な詳細

「小さなプロジェクト」とは何ですか？

この記事で検討したアーキテクチャは、さまざまな方向の多くのプロジェクトで既に実装されています。これらは、マスメディア、オンラインストア、オンラインゲーム、ソーシャルネットワーク、ブロックチェーンプラットフォームなどです。



それが設計されている小さなプロジェクトとは何ですか？ 基準はそれほど厳密ではありませんが、主な傾向と要件を示しています。

• これはすでに複数のサーバーがあるプロジェクトです（アーキテクチャは多くのサーバーに展開できるため、名前の上限は正しくありません）。
• プロジェクトはビジネスツールであり、利益を上げるため、すでにフォールトトレランスが必要です。
• プロジェクトは高負荷に対応する必要があり、迅速に拡張できる機能が本当に必要です（たとえば、オンラインストアはブラックフライデーの前に一時的にサーバー容量を増やす必要があります）。
• プロジェクトにはシステム管理者が必要です。これがないと何も起こらないからです。

アーキテクチャ全体を簡単に説明すると、これは「Kubernetesによって管理されるDockerコンテナのフォールトトレラントでスケーラブルなクラウド」と言えます。 そして、ここに含まれるものは...

Kubernetesアプリ

以下では、典型的なオンラインストアを例として取り上げます。 Kubernetesクラスターが展開されている3つのサーバーがあると想像してください。 Kubernetesはアーキテクチャの主要コンポーネントであり、Dockerコンテナのオーケストレーションとその管理に関与するコンポーネントです。 彼は、クライアントアプリケーションが実行されるコンテナの信頼性が高く、フォールトトレラントでスケーラブルな操作を担当しています。 すなわち 実際、3つのサーバーで実行されているコンテナーのクラウドです。 クラウドが実行されているサーバーの1つに障害が発生した場合、Kubernetesはドロップされたコンテナー（落下したサーバー上で実行）を残りの2つのサーバーに自動的にスローします。これは数秒以内に非常に高速に発生します。







私たちの目標-クラウド内の1台のサーバーまたは2台のサーバーの落下は目立たないイベントである必要があります。 これは、各コンポーネントが少なくとも1回複製され、1つのコンポーネントのインスタンスがクラウド内の異なるサーバーに配置されるという事実により実現されます。 同時に、バックアップコンポーネントはすぐに自身の負担を負う準備ができています。 アプリケーションがサポートしている場合、コンポーネントのすべてのインスタンスが同時に動作し、「メイン予約」モードではない可能性があります。 「スケール」ボタンをクリックして、このコンポーネントの別の1つ、2つ、3つ、またはそれ以上の追加インスタンスを取得することもできます。



オンラインストアがPHPで記述されており、次のコンポーネントが含まれているとします*：

• MySQLデータベース
• PHPバックエンド
• memcachedキャッシング
• RabbitMQキュー
• Redisでの注文の保管。
• 消費者
• cronタスク。

*実際には、これがオンラインストアであるかメディアサイトであるかはそれほど重要ではなく、コンポーネント自体もまったく異なる場合がありますが、本質は同じままです。



ご想像のとおり、私たちの仕事の一部は、アプリケーション（この場合はオンラインストア）をDockerコンテナーにパックしてから、これらのコンテナーをKubernetesクラウドで起動することです。 アプリケーション自体（PHPバックエンド）に加えて、クラウドで機能する他のコンポーネント（memcached、RabbitMQなど）



注 ：技術的な理由により、Kubernetesクラウド内に本番環境でRDBMSをインストールすることはまだありません。 しかし、彼らは、本番環境ではない小さなプロジェクトやアプリケーション（dev-contoursなど）向けに、このようなインストールを最初に行い始めました。







多くの場合、すべてのプロジェクトにはほぼ同じコンポーネントのスタックがあり、プログラミング言語とデータベースに違いがある可能性が高くなります。 Kubernetesの導入により、これらの各コンポーネントの典型的な構成を実装する良い機会が与えられました。これは、あらゆるプロジェクトに適しています。 同時に、このような典型的なコンポーネントはそれ自体でフォールトトレラントであり、容易に拡張でき、5分以内にKubernetesクラスターにもインストールされます。 例として、各コンポーネントを個別に検討します。

データベース

ほとんどの場合、DBMSはKubernetesの外部にあり、通常、マスタースレーブモード（MySQL、PostgreSQLなど）またはマスターマスター（Percona XtraDB）で動作する2つまたは3つのサーバーで構成されているため、DBMSは別のエンティティとして割り当てられます。緊急時の自動または手動フェールオーバー。

PHPバックエンド

バックエンドは、Dockerコンテナにパッケージ化されたアプリケーションコードです。 アプリケーションに必要なライブラリとソフトウェアは、このコンテナにインストールされます（たとえば、PHP 7）。 同じコンテナを使用して、コンシューマタスクとcronタスクを実行します。 Kubernetesでは、複数のバックエンドインスタンス、1つのクラウン、および複数のコンシューマーを起動しています。

Memcached

memcachedを使用して、さまざまな状況で使用される2つの実装オプションを歴史的に開発してきました。

• N個の個別のmemcachedインスタンス（通常3）。 アプリケーションは、3つすべてのmemcachedを認識し、3つすべてに書き込み、フェイルオーバー自体を提供します。
• Mcrouterは、あらゆるアプリケーションに適合する汎用オプションです。 分散書き込みおよびフェールオーバーロジックは、マクロター側のアプリケーションから取り出されます。

うさぎ

Kubernetesレベルで自動フェールオーバーを行う3つ以上のノードの通常のRabbitMQクラスターを使用します。

レディス

このコンポーネントの中心で、通常のRedis Sentinelクラスターを使用します。これには、アプリケーションがセンチネルプロトコルを実装する必要性を排除するバインディングがあります。

その他のアプリケーションサービス

同様に、minio、sphinxsearch、elasticsearch、その他多くの既製およびテスト済みのコンポーネントを保有しています。 ほとんどすべてのソフトウェアをKubernetes内にインストールできます。主なことは、このプロセスに賢明にアプローチすることです。

サービス部品

各プロジェクトには、次のKubernetesユーティリティコンポーネントもあります。

• 開発者がコンポーネントを管理できるようにするコントロールパネル（ダッシュボード）。 また、それを介してコンテナ内に入ることができます-SSHのように。
• 集中ログストレージ。 ログはすべての回路のすべてのコンポーネントからリアルタイムで収集され、ログは単一のデータベースに書き込まれます。 すべてのログをリアルタイムで表示し、さまざまなパラメーターで検索およびフィルターする機能を備えたWebインターフェースを使用できます。 このために、 この発表で読む詳細については、独自のオープンソースソリューションログハウスを使用します。
• Prometheus + Okmeterで監視します。 PrometheusはKubernetes内にインストールされ、すべてのコンポーネントから統計を収集します。 標準パラメーター（メモリ、ディスク、CPU）に加えて、メトリックはApache / php-fpm、RabbitMQ、Redisなどからも取得されます。 -各コンポーネントは個別に監視されます。 OkmeterはKubernetesの外に立ち、サーバー自体を外部から監視します。

アーキテクチャコンサルティングとステートレス

原則として、最初に私たちに届くプロジェクトには、アーキテクチャに関する問題があります。主に、ディスク上のファイルまたは中間データの保存、セッションのローカルストレージ、および他の多くの理由によるスケーリングです。 仕事の最大かつ最も難しい部分は、開発者がアプリケーションを作り直してステートレスになるようにすることです。



それが完全に手元にある場合、これはアプリケーションの各コンポーネントが中間データを保存しないこと、またはこのデータはほとんど重要ではなく、安全に失われる可能性があることを意味します。 これは、複数のバックエンドを起動し、そのうちの1つが突然失敗した場合に何も壊れず、ユーザーがダウンロードしたファイルが削除されないようにするために必要です。



ステートレスアプリケーションを困難にする最も一般的な理由は次のとおりです。

1. バックエンドでのセッションのローカルストレージ（ファイル内）。 この問題は、ほとんどの場合、セッションをフォールトトレラントmemcachedに入れるだけで解決されます（PHP設定またはアプリケーション設定）。
2. バックエンドのダウンロードファイルのローカルストレージ。 この問題は、専用のファイルストレージ（たとえば、Amazon S3またはSelectelのファイルストレージ）またはminioまたはCeph（S3 / Swift API）に実装されたクライアントサーバー上のストレージのオプションを使用することで解決されます。

このようなステートレスな未来に関する懸念への答えは（そう、あなたは本当にアプリケーションの変更に開発者のリソースを費やす必要があります）、それはとにかく避けられないことです（スケーリングが必要なアプリケーションの場合）、段階的にアプローチすることができます。

その他の問題と機能

CI / CD

最後に、このようなインフラストラクチャにアプリケーションコードをどのように展開するかについて、論理的な疑問が生じます。 次のように配置されます。

1. コードはバージョン管理システム（Git）によって管理されます。
2. GitLab *を使用して、コードのコミット後にDockerコンテナーのアセンブリを呼び出します。
3. GitLabのビルドフェーズの後、「実稼働環境にロールアウト」ボタンが表示されます。
4. このボタンを押します-アプリケーションの新しいバージョンがロールアウトして起動し、古いバージョンが停止し、ロールアウトがサイトユーザーに対してシームレスかつ目に見えないように行われます。 また、ロールアウト中に、データベースの移行が実行されます。

Kubernetesには名前空間があります。 それらは、同じクラスターで実行される個別の分離された回路または環境と考えることができます。 つまり、ステージング用、マスターブランチ用、またはブランチごとに個別のパスを作成する機会があります。 輪郭は生産の完全なコピーです。すべての同じコンポーネント（MySQL、バックエンド、Redis、RabbitMQなど）があります。 これは、インフラストラクチャ設定全体（すべてのコンポーネントの設定）が特別なYAMLファイルで記述され、リポジトリにあるという事実により実現されます。つまり、他のネームスペースで本番環境を迅速かつ完全に再作成する機会を得ます。







* GitLab CIのパイプラインの例とその実装の技術的な詳細については、 この記事をご覧ください 。

サーバー

最も一般的なインストールは、E5-1650v4、128G RAM、2×500 GB SSDの構成を備えた3つのハイパーバイザーサーバーです。 サーバーはローカルネットワークによって相互接続されます。 各サーバーのリソースは、仮想マシン（Linux KVM + QEMU）を使用して次の部分に分割されます。

• 生産回路;
• 開発回路
• Kubernetesサービスサービス（マスターとフロント）;
• データベース。

バックアップ

データベース、アップロードファイルなど、プロジェクトに必要なすべてをバックアップします。 バックアップ中にダウンタイムは発生しません（DBMSの場合、データはスレーブサーバーから削除されます）。 バックアップ計画とその月次テストはクライアントと合意されています-個人のプロジェクトマネージャーがこれを担当します。

監視と相互作用

これらは常に技術的な問題ではありませんが、継続的なサポートの全体像を理解するために重要です。

• 私たちが利用できる監視ツールのおかげで、すべてのアラートは勤務エンジニア向けの集中管理されたインターフェースに流れます。 各インシデントを処理する必要があり、それぞれに要約が必要です。 アラートへの平均応答時間は1分（トリアージの場合は10分）ですが、アラートへの応答は15分以内に保証されます。 電話、スラック、郵便、チケットシステム（Redmine）で24時間体制で勤務するエンジニア。
• 各プロジェクトには、専任のマネージャーと、一流のエンジニア、普通のエンジニア、ジュニアエンジニアを含むエンジニアの専任チームがいます。 これらの人々は変わりません。彼らはプロジェクトの最初から「生きて」おり、その仕組みを完全に理解しています。
• シンプルなビジネスクリティカルなインフラストラクチャに対する罰金を含むSLA保証を提供しています。

要約する

現代のクラウドネイティブインフラストラクチャソリューションは、今やすべての人にとって有効であり、その使用コストは宇宙船の価格に匹敵すべきではないと考えています。 モバイル通信との類似性を引き出すことができます。モバイル通信がエリートのみが利用できるようになる前であれば、今日では当たり前のことであり、通信の価格は安いです。



「Linuxでのすべて」の「手動」管理からKubernetesに基づく最新のインフラストラクチャのサポートに移行して、合理的な「規範」と見なされるサービスが、予算を問わず顧客にアクセスできるように努めています。 したがって、スタッフが雇用したシステム管理者/ DevOpsエンジニアの給与レベルの予算内で、24時間体制のサポートとSLA保証を備えたDevOpsの原則に従って（開発者と緊密に協力して）そのようなインフラストラクチャを実装/保守する専門家の専門チームを提供します。



ここで簡単に説明したインフラストラクチャの多くの技術的側面（および関連するベストプラクティス）にはかなりの詳細がありますが、これは個々の記事の話です：それらの一部が既にブログで公開されている場合、コメントで新しいもののリクエストを歓迎します。 技術に関連する問題ではなく、仕事で使用するプロセスや、サービスの一部としてクライアントに提供するプロセスに関連する問題に喜んで対処します。

PS

ブログもご覧ください。

• 「 小規模プロジェクトでのKubernetesでの経験 」 （Kubernetesの技術デバイスの紹介を含むビデオレポート）;
• 制作におけるKubernetesのサクセスストーリーに関するシリーズ：「 No. 1：eBayによる4,200ポッドとTessMaster 」、「 No。2：ConcurとSAP 」、「 No。3：GitHub 」、「 No。4：SoundCloud（著者Prometheus） 」
• 「 Kubernetesの実装の難しさに関する新しいスタック統計 」;
• 「 Kubernetesが必要な理由とPaaSよりも大きい理由 」