Amazon EKSを生産用戦艦として

機会

このケーススタディの中心にいる顧客は、海運業界で評判の高いグローバルブランドです。世界中の貨物船オーナーに包括的な船舶管理サービスを提供しており、陸上と海上の両方でプロフェッショナルな労働力を持っています。同社は以下の注目すべき機能を備えた包括的なウェブベースのプラットフォームを運営しています。

  • 業界全体にわたるB2Bサービス。
  • 船舶/船主のための重要な指標をリアルタイムで監視し、乗組員の詳細、メンテナンススケジュール、船舶の性能などを含みます。
  • 600隻以上の船舶を追跡。

顧客は、現在のアーキテクチャとアプリケーション環境の評価と改善を行うためにSourceFuseを任命しました。アカウントにアクセスし、詳細な調査を行った後、SourceFuseは以下のハイライトを含む報告書を提出しました。

  • 彼らのシステムは、現在の安定した信頼性のある状態に達するまでに様々な有機的な改訂を経てきました。
  • 同社は、開発者の体験を向上させ、デバッグ技術を改善するために、全体的なアプリケーションの可視性を向上させることを目指していました。
  • サイバーセキュリティリスクをさらに低減するために、現在のセキュリティ姿勢を再検討することに熱心でした。
  • 現在の状態に至る成功の過程で、AWSのEC2、Lambda、ECS上のコンテナなど、様々な種類のコンピューティングサービスが利用されていました。

解決策

段階的な改善アプローチの一環として、SourceFuseは実績のあるアプローチを採用し、顧客のコンピュートをAmazon EKSに移行し、高い信頼性と可用性を持つ構成を実現しました。同時に、AWSのセキュリティベストプラクティスを使用してセキュリティを強化しました。

EKSは、AWS上でクラスターを管理するための柔軟性と制御を提供し、上級ユーザーが管理できるようにしますが、EKSは他のAWSネイティブサービスとの統合を簡素化する管理ソリューションを提供します。これらの機能により、運用の負担を最小限に抑え、AWSエコシステム全体の恩恵を受けながら、デフォルトのKubernetes機能を活用したい組織にとって魅力的な選択肢となります。

SourceFuseがEKS展開において持つ深い経験に基づき、以下のラインでよく設計された、安全で信頼性のあるアーキテクチャを提供しました。

  • 自動化されたクラスターの展開と更新: 完全なクラスターとその構成パラメーターはTerraform CLIを介して制御されました。Terraformはインフラストラクチャのプロビジョニングを自動化するためのさまざまなプロバイダーを提供します。オープンソース版のTerraformを拡張して、エンタープライズグレードの ARC-IaC by SourceFuse を作成し、すべてのAWSベストプラクティスを組み込み、カスタム要件に応じて構成可能です。
ブロック図 — インフラ展開
  • 自動化された統合と展開: 顧客はクラスター上に多様なアプリケーションを展開する必要があります。コードベースとIaCはBitBucketで管理されており、信頼性のあるインフラ管理ツールが必要でした。SourceFuseはArgoCDを実装して、EKSクラスター全体で宣言型デリバリーメソッドを活用しました。また、Jenkinsを活用して継続的なテストパイプラインを設定しました。
ArgoCD — EKS継続的展開ツール
  • リソース分離によるマルチテナンシー: EKSではデフォルトでマルチテナンシーの分離は提供されませんが、以下のプラクティスを使用して実現しました:

a) ネームスペース – 各テナントは共有クラスターに参加し、それぞれのワークロードは指定されたネームスペースのセットにのみ限定されます。一方、スケジューラ、APIサーバー、CPU、メモリなどのすべてのコントロールプレーンリソースは、クラスター全体で全テナントがアクセス可能です。

テナントのワークロードが分離されているため、ネームスペースにはロールバインディング、リソースクォータ、ネットワークポリシーなどの重要なコンポーネントが含まれています。これらのコンポーネントは特定の機能を果たすために意図的にネームスペースに統合されています。ロールバインディングはネームスペース内でのアクセスを制御し、ネットワークポリシーはネットワークトラフィックの分離に寄与し、全体的なセキュリティを強化します。

本質的に、この共有クラスターエコシステム内のアプローチは、リソース共有とワークロードの分離のバランスを取ります。ワークロードを割り当てられたネームスペースに限定することで、テナントはクラスターリソースを効果的に活用でき、各ネームスペースに組み込まれたコンポーネントはアクセス制御、使用制限、ネットワークトラフィックの防止のためのツールとして機能します。

b) ロールベースのアクセス制御(RBAC) – RBACは、クラスターまたはネームスペース内でユーザーが実行できるアクションを定義するClusterRolesとRolesを使用して実装されました。SourceFuseはこれらのロールをKubernetesのサブジェクト(ユーザー、グループ、または サービスアカウント )にロールバインディングとクラスターロールバインディングで割り当てました。

c) リソースクォータ – リソースクォータは非常に詳細なレベルで設定されました。Podが十分な利用可能リソースを持つノードで実行される場合、そのリソースの要求されたリソース割り当てを超えることが可能であり許可されます。このプラクティスは各テナントの使用制限を設定し、リソースの枯渇を防ぎます。それでも、コンテナは定義されたリソース制限を超えてはなりません。

  • 監視と可観測性: クラウドに依存しないOBFスタックが展開され、顧客がワークロードの最大の可視性を持てるようにしました。完全なスタックを作成するために組み合わされたツールには以下が含まれます:
a) Prometheus Grafana はHelm ChartとArgoCDを使用して展開されました。これに加えて、 swagger-stats がPrometheus形式でメトリクスを公開するために実装され、APIの監視とアラートに同じツールセットを使用できるようにしました。 b) Fluent-bit Logstash 、および OpenSearch の組み合わせを活用して、EKSクラスターからOpenSearchにすべてのアプリケーションログとPODログをスクレイプしてプッシュし、集中検索可能なダンプを作成しました。
集中ログ分析
  • セキュリティとコンプライアンス:

a) ランタイムセキュリティ – コンテナがコンテナ内で特定の境界を超えて実行しないように制限しました。SeccompはLinuxカーネルの機能であり、アプリケーションのアクセスを制限するために活用しました。これにより、システムコールを無効にすることで、アーキテクチャの被害範囲を制限できます。

b) イメージスキャン – すべてのプライベートレジストリリポジトリに対して、プッシュ時にスキャンする機能を有効にしました。Amazon ECRはスキャン結果のリストを提供します。さらに、各コンテナイメージは少なくとも1日1回スキャンされます。Amazon ECRはオープンソースのClairプロジェクトの共通脆弱性と露出(CVEs)データベースを使用し、スキャン結果のリストを提供します。

上記のすべての機能は、ボックスからは利用できないものであり、SourceFuseはEKS上での生産ワークロードを可能にし、コンテナ化されたワークロードのためのAWSベストプラクティスのすべてのチェックボックスを満たしました。

顧客について

中国香港特別行政区に本社を置く同社は、12か国に27のオフィスを持ち、グローバルに展開しています。顧客基盤は、中国、ギリシャ、インド、日本、韓国、オランダ、ノルウェー、トルコ、米国などのフォーチュン500企業を含む100以上の世界的な船主に及びます。現在、650以上の多様なタイプの船舶を管理する最大の独立した第三者船舶管理会社の一つです。

ケーススタディPDFをダウンロード