From 7332a28c24a758e3f39b22734198ef6da9786e44 Mon Sep 17 00:00:00 2001 From: inductor Date: Wed, 26 May 2021 13:20:28 +0000 Subject: [PATCH] revert case studies --- content/ja/case-studies/appdirect/index.html | 112 ++++++------- .../ja/case-studies/chinaunicom/index.html | 134 ++++++++------- content/ja/case-studies/nav/index.html | 129 ++++++++------- content/ja/case-studies/nordstrom/index.html | 153 +++++++++++------- content/ja/case-studies/sos/index.html | 134 ++++++++------- content/ja/case-studies/spotify/index.html | 144 +++++++++++------ 6 files changed, 461 insertions(+), 345 deletions(-) diff --git a/content/ja/case-studies/appdirect/index.html b/content/ja/case-studies/appdirect/index.html index a5ef3a354b..e2b8948bf6 100644 --- a/content/ja/case-studies/appdirect/index.html +++ b/content/ja/case-studies/appdirect/index.html @@ -1,84 +1,70 @@ --- title: AppDirect ケーススタディ + linkTitle: AppDirect case_study_styles: true cid: caseStudies +css: /css/style_case_studies.css logo: appdirect_featured_logo.png featured: true weight: 4 quote: > 私たちはたくさんの人からの関心を得るためにさまざまな戦略を試みています。Kubernetesとクラウドネイティブ技術は、いまやデファクトのエコシステムとみなされています。 - -new_case_study_styles: true -heading_background: /images/case-studies/appdirect/banner1.jpg -heading_title_logo: /images/appdirect_logo.png -title_prefix: "ケーススタディ：" -subheading: > - AppDirect：AppDirectはいかにしてKubernetessを活用し、エンジニアリングスタッフが10倍になるほどの成長を後押ししたのか -case_study_details: - - 企業名: AppDirect - - 所在地: カリフォルニア州サンフランシスコ - - 業界: ソフトウェア --- -

課題

+
+

ケーススタディ：
AppDirect：AppDirectはいかにしてKubernetessを活用し、エンジニアリングスタッフが10倍になるほどの成長を後押ししたのか
-

AppDirect はクラウドベースの製品やサービス向けにエンドツーエンドのeコマースプラットフォームを提供しています。2014年、ソフトウェア開発ディレクターであるPierre-Alexandre LacerteがAppDirectで働き始めた時、同社は「Tomcatベースのインフラにモノリシックなアプリケーションをデプロイしていて、リリースプロセス全体が必要以上に複雑になっていました」と彼は振り返ります。「たくさんのマニュアルステップがありました。1人のエンジニアがある機能を構築し、それから別のチームがその変更を取り込むといった具合です。そのため、提供までのパイプラインにボトルネックがあったのです。」これと同時に、エンジニアリングチームが大きくなっていき、その成長を後押しし加速する上でも、より良いインフラが必要であることに同社は気づいたのです。

+

-

ソリューション

+
-

Lacerteは言います。「私のアイデアは、チームがサービスをもっと高速にデプロイできる環境を作ろうぜ、というものです。そうすれば彼らも『そうだね、モノリスはもう建てたくないしサービスを構築したいよ』と言うでしょう。」彼らは、2016年初めKubernetes の採用を決定するにあたり、他のいくつかの技術を調査・検討し、プロトタイプを作りました。 Lacerteのチームはこのプラットフォームへの監視のためにPrometheus モニタリングツールを統合しました。この次にあるのはトレーシングです。今やAppDirectは本番環境で50以上のマイクロサービス、15のKubernetesクラスターをAWS 上や世界中のオンプレミス環境で展開しています。

+
企業名  AppDirect     所在地  カリフォルニア州サンフランシスコ     業界 ソフトウェア +
-

インパクト

- -

Kubernetesプラットフォームは、エンジニアリングチームのここ数年の10倍成長を後押ししてきました。彼らが継続的に機能追加しているという事実と相まって「この新たなインフラがなければ、我々は大幅なスローダウンを強いられていたと思います」と、Lacerte氏は述べています。Kubernetesとサービス化へ移行していくことは、SCPコマンドを用いた、カスタムメイドで不安定なシェルスクリプトへの依存性を弱め、非常に高速になったことを意味していました。新しいバージョンをデプロイする時間は4時間から数分間に短縮されました。こういったことに加え同社は、開発者たちが自らのサービスとして仕立て上げるよう、数多くの努力をしてきました。「新しいサービスを始めるのにJira のチケットや他のチームとのミーティングはもはや必要ないのです」とLacerte氏は言います。以前、週あたり1〜30だった同社のデプロイ数は、いまや週1,600デプロイにまでなっています。また、同社はビジネスアワーにおけるトラフィックの増加に応じ、自社のマーケットプレイスや課金周りのモノリシックだったシステムを従来のEC2ホストからKubernetesに移し、オートスケール機能を活用することと併せてコスト削減を実現できました。

- -{{< case-studies/quote author="AppDirect ソフトウェア開発 ディレクター Pierre-Alexandre Lacerte" >}} -「計り知れないほどのエンジニアリング文化のシフトでしたが、規模とスピードを考えるとそのメリットは否定できません。」 -{{< /case-studies/quote >}} - -{{< case-studies/lead >}} -AppDirect は2009年以来、クラウドベースの製品やサービス向けのエンドツーエンドのeコマースプラットフォームによって、ComcastやGoDaddyといった組織がデジタルサプライチェーンをシンプルにすることに役立ってきました。 -{{< /case-studies/lead >}} - -

2014年にソフトウェア開発ディレクターのPierre-Alexandre Lacerteが働き始めたとき、AppDirectでは「tomcatベースのインフラにモノリシックなアプリケーションをデプロイしていて、リリースプロセス全体が必要以上に複雑なものとなっていました」と彼は振り返ります。「たくさんのマニュアルステップがありました。1人のエンジニアがある機能を構築し、Pull requestを作成、そしてQAもしくは別のエンジニアの手によってその機能を検証する、といった具合でした。さらにこれがマージされれば、また別の誰かがデプロイ作業の面倒をみることになるでしょう。そのため、提供までのパイプラインにボトルネックがいくつもありました。」

- -

これと同時に、40人のエンジニアリングチームが大きくなっていくにつれ、その成長を後押しし加速する上でも、より良いインフラが必要となってくることに同社は気づいたのです。そのころプラットフォーム チームの一員であったLacerteには、Node.js に Spring Boot Javaといった、異なるフレームワークや言語を使いたいといった声が複数のチームから聞こえてくるようになってきました。同社の成長とスピードを両立するには、(チームが自律的に動き、自らがデプロイし、稼働中のサービスに責任を持てるような)よりよいインフラやシステムがこの会社には必要だということに彼はすぐに気づいたのです。

- -{{< case-studies/quote - image="/images/case-studies/appdirect/banner3.jpg" - author="AppDirect ソフトウェア開発者　Alexandre Gervais" ->}} -「正しいタイミングで正しい判断ができました。Kubernetesとクラウドネイティブ技術は、いまやデファクトのエコシステムとみなされています。スケールアウトしていく中で直面する新たな難題に取り組むにはどこに注力すべきか、私たちはわかっています。このコミュニティはとても活発で、当社の優秀なチームをすばらしく補完してくれています。」 -{{< /case-studies/quote >}} - -

Lacerteは当初から言っていました。「私のアイデアは、チームがサービスをもっと高速にデプロイできる環境を作ろう、というものです。そうすれば彼らもこう言うでしょう『そうだよ、モノリスを建てるなんてもうしたくないしサービスを構築したいんだ』と」(Lacerteは2019年に同社を退社)。

- -

Lacerteのグループは運用チームと連携することで同社の AWSのインフラにより多くアクセスし、コントロールするようになりました。そして、いくつかのオーケストレーション技術のプロトタイプを作り始めたのです。「当時を振り返ると、Kubernetesはちょっとアンダーグラウンドというか、それほど知られていなかったように思います。」と彼は言います。「しかし、コミュニティやPull requestの数、GitHub上でのスピードなどをよく見てみると勢いが増してきていることがわかりました。他の技術よりも管理がはるかに簡単であることもわかりました。」彼らは、Kubernetes上で Chef やTerraform によるプロビジョニングを用いながら最初のいくつかのサービスを開発しました。その後さらにサービスも、自動化されるところも増えました。「韓国、オーストラリア、ドイツ、そしてアメリカ、私たちのクラスターは世界中にあります。」とLacerteは言います。「自動化は私たちにとって極めて重要です。」今彼らは大部分でKopsを使っていて、いくつかのクラウドプロバイダーから提供されるマネージドKubernetesサービスも視野に入れていれています。

- -

今もモノリスは存在してはいますが、コミットや機能はどんどん少なくなってきています。あらゆるチームがこの新たなインフラ上でデプロイしていて、それらはサービスとして提供されるのが一般的です。今やAppDirectは本番環境で50以上のマイクロサービス、15のKubernetesクラスターをAWS上や世界中のオンプレミス環境で展開しています。

- -

Kubernetesプラットフォームがデプロイ時間に非常に大きなインパクトを与えたことから、Lacerteの戦略が究極的に機能しました。カスタムメイドで不安定だった、SCPコマンドを用いたシェルスクリプトに対する依存性を弱めることで、新しいバージョンをデプロイする時間は4時間から数分にまで短縮されるようになったのです。こういったことに加え同社は、開発者たちが自らのサービスとして仕立て上げるよう、数多くの努力をしてきました。「新しいサービスを始めるのに、 Jiraのチケットや他のチームとのミーティングはもはや必要ないのです」とLacerteは言います。以前、週あたり1〜30だった同社のデプロイ数は、いまや週1,600デプロイにまでなっています。

- -{{< case-studies/quote - image="/images/case-studies/appdirect/banner4.jpg" - author="AppDirect ソフトウェア開発 ディレクター Pierre-Alexandre Lacerte" ->}} -「この新たなインフラがなければ、我々は大幅なスローダウンを強いられていたと思います。」 -{{< /case-studies/quote >}} +
+
+
+
+

課題

AppDirect はクラウドベースの製品やサービス向けにエンドツーエンドのeコマースプラットフォームを提供しています。2014年、ソフトウェア開発ディレクターであるPierre-Alexandre LacerteがAppDirectで働き始めた時、同社は「Tomcatベースのインフラにモノリシックなアプリケーションをデプロイしていて、リリースプロセス全体が必要以上に複雑になっていました」と彼は振り返ります。「たくさんのマニュアルステップがありました。1人のエンジニアがある機能を構築し、それから別のチームがその変更を取り込むといった具合です。 +そのため、提供までのパイプラインにボトルネックがあったのです。」 +これと同時に、エンジニアリングチームが大きくなっていき、その成長を後押しし加速する上でも、より良いインフラが必要であることに同社は気づいたのです。 +

ソリューション

Lacerteは言います。「私のアイデアは、チームがサービスをもっと高速にデプロイできる環境を作ろうぜ、というものです。そうすれば彼らも『そうだね、モノリスはもう建てたくないしサービスを構築したいよ』と言うでしょう。」 +彼らは、2016年初めKubernetes の採用を決定するにあたり、他のいくつかの技術を調査・検討し、プロトタイプを作りました。 Lacerteのチームはこのプラットフォームへの監視のためにPrometheus +モニタリングツールを統合しました。この次にあるのはトレーシングです。今やAppDirectは本番環境で50以上のマイクロサービス、15のKubernetesクラスターをAWS 上や世界中のオンプレミス環境で展開しています。

インパクト

Kubernetesプラットフォームは、エンジニアリングチームのここ数年の10倍成長を後押ししてきました。 +彼らが継続的に機能追加しているという事実と相まって「この新たなインフラがなければ、我々は大幅なスローダウンを強いられていたと思います」と、Lacerte氏は述べています。Kubernetesとサービス化へ移行していくことは、SCPコマンドを用いた、カスタムメイドで不安定なシェルスクリプトへの依存性を弱め、非常に高速になったことを意味していました。 +新しいバージョンをデプロイする時間は4時間から数分間に短縮されました。 +こういったことに加え同社は、開発者たちが自らのサービスとして仕立て上げるよう、数多くの努力をしてきました。「新しいサービスを始めるのにJira のチケットや他のチームとのミーティングはもはや必要ないのです」とLacerte氏は言います。 +以前、週あたり1〜30だった同社のデプロイ数は、いまや週1,600デプロイにまでなっています。 +また、同社はビジネスアワーにおけるトラフィックの増加に応じ、自社のマーケットプレイスや課金周りのモノリシックだったシステムを従来のEC2ホストからKubernetesに移し、オートスケール機能を活用することと併せてコスト削減を実現できました。 +
+
+
+
+
「計り知れないほどのエンジニアリング文化のシフトでしたが、規模とスピードを考えるとそのメリットは否定できません。」

- AppDirect ソフトウェア開発 ディレクター Pierre-Alexandre Lacerte
+
+
+
+

AppDirect は2009年以来、クラウドベースの製品やサービス向けのエンドツーエンドのeコマースプラットフォームによって、ComcastやGoDaddyといった組織がデジタルサプライチェーンをシンプルにすることに役立ってきました。


2014年にソフトウェア開発ディレクターのPierre-Alexandre Lacerteが働き始めたとき、AppDirectでは「tomcatベースのインフラにモノリシックなアプリケーションをデプロイしていて、リリースプロセス全体が必要以上に複雑なものとなっていました」と彼は振り返ります。「たくさんのマニュアルステップがありました。1人のエンジニアがある機能を構築し、Pull requestを作成、そしてQAもしくは別のエンジニアの手によってその機能を検証する、といった具合でした。さらにこれがマージされれば、また別の誰かがデプロイ作業の面倒をみることになるでしょう。そのため、提供までのパイプラインにボトルネックがいくつもありました。」

これと同時に、40人のエンジニアリングチームが大きくなっていくにつれ、その成長を後押しし加速する上でも、より良いインフラが必要となってくることに同社は気づいたのです。そのころプラットフォーム チームの一員であったLacerteには、Node.js に Spring Boot Javaといった、異なるフレームワークや言語を使いたいといった声が複数のチームから聞こえてくるようになってきました。同社の成長とスピードを両立するには、(チームが自律的に動き、自らがデプロイし、稼働中のサービスに責任を持てるような)よりよいインフラやシステムがこの会社には必要だということに彼はすぐに気づいたのです。
+
+
+
「正しいタイミングで正しい判断ができました。Kubernetesとクラウドネイティブ技術は、いまやデファクトのエコシステムとみなされています。スケールアウトしていく中で直面する新たな難題に取り組むにはどこに注力すべきか、私たちはわかっています。このコミュニティはとても活発で、当社の優秀なチームをすばらしく補完してくれています。」

- AppDirect ソフトウェア開発者　Alexandre Gervais
+
+
+
Lacerteは当初から言っていました。「私のアイデアは、チームがサービスをもっと高速にデプロイできる環境を作ろう、というものです。そうすれば彼らもこう言うでしょう『そうだよ、モノリスを建てるなんてもうしたくないしサービスを構築したいんだ』と」(Lacerteは2019年に同社を退社)。

Lacerteのグループは運用チームと連携することで同社の AWSのインフラにより多くアクセスし、コントロールするようになりました。そして、いくつかのオーケストレーション技術のプロトタイプを作り始めたのです。「当時を振り返ると、Kubernetesはちょっとアンダーグラウンドというか、それほど知られていなかったように思います。」と彼は言います。「しかし、コミュニティやPull requestの数、GitHub上でのスピードなどをよく見てみると勢いが増してきていることがわかりました。他の技術よりも管理がはるかに簡単であることもわかりました。」彼らは、Kubernetes上で Chef やTerraform によるプロビジョニングを用いながら最初のいくつかのサービスを開発しました。その後さらにサービスも、自動化されるところも増えました。「韓国、オーストラリア、ドイツ、そしてアメリカ、私たちのクラスターは世界中にあります。」とLacerteは言います。「自動化は私たちにとって極めて重要です。」今彼らは大部分でKopsを使っていて、いくつかのクラウドプロバイダーから提供されるマネージドKubernetesサービスも視野に入れていれています。

今もモノリスは存在してはいますが、コミットや機能はどんどん少なくなってきています。あらゆるチームがこの新たなインフラ上でデプロイしていて、それらはサービスとして提供されるのが一般的です。今やAppDirectは本番環境で50以上のマイクロサービス、15のKubernetesクラスターをAWS上や世界中のオンプレミス環境で展開しています。

Kubernetesプラットフォームがデプロイ時間に非常に大きなインパクトを与えたことから、Lacerteの戦略が究極的に機能しました。カスタムメイドで不安定だった、SCPコマンドを用いたシェルスクリプトに対する依存性を弱めることで、新しいバージョンをデプロイする時間は4時間から数分にまで短縮されるようになったのです。こういったことに加え同社は、開発者たちが自らのサービスとして仕立て上げるよう、数多くの努力をしてきました。「新しいサービスを始めるのに、 Jiraのチケットや他のチームとのミーティングはもはや必要ないのです」とLacerteは言います。以前、週あたり1〜30だった同社のデプロイ数は、いまや週1,600デプロイにまでなっています。 +
+
+
+
「この新たなインフラがなければ、我々は大幅なスローダウンを強いられていたと思います。」

- AppDirect ソフトウェア開発 ディレクター Pierre-Alexandre Lacerte
+
-

さらに、Kubernetesプラットフォームは、エンジニアリングチームがこの数年で10倍も拡大したことを後押してきたともいえます。「AppDirectのコアバリューの1つとして掲げている『Ownership』には、モノリシックなコードベースに依存しないでサービス提供ができる、当社の能力が反映されていると思います。」とLacerteとこの取り組みに参加したソフトウェア開発者のAlexandre Gervaisは述べています。「いまや小さなチームでも当社のビジネスドメインモデルの非常に重要な部分を所有(own)しています。彼らは、コードベース全体についての知識は限られていますが、専門領域として切り離された形でチームをオペレーションしているのです。こういったやり方が、複雑性を緩和することに繋がっています。」彼らが継続的に機能追加しているという事実と相まって「この新たなインフラがなければ、我々は大幅なスローダウンを強いられていたと思います。」と、Lacerte氏は述べています。同社はビジネスアワーにおけるトラフィックの増加に応じ、自社のマーケットプレイスや課金周りのモノリシックだったシステムを従来のEC2ホストからKubernetesに移し、オートスケール機能を活用することと併せてコスト削減を実現することもできました

+
さらに、Kubernetesプラットフォームは、エンジニアリングチームがこの数年で10倍も拡大したことを後押してきたともいえます。「AppDirectのコアバリューの1つとして掲げている『Ownership』には、モノリシックなコードベースに依存しないでサービス提供ができる、当社の能力が反映されていると思います。」とLacerteとこの取り組みに参加したソフトウェア開発者のAlexandre Gervaisは述べています。「いまや小さなチームでも当社のビジネスドメインモデルの非常に重要な部分を所有(own)しています。彼らは、コードベース全体についての知識は限られていますが、専門領域として切り離された形でチームをオペレーションしているのです。こういったやり方が、複雑性を緩和することに繋がっています。」彼らが継続的に機能追加しているという事実と相まって「この新たなインフラがなければ、我々は大幅なスローダウンを強いられていたと思います。」と、Lacerte氏は述べています。同社はビジネスアワーにおけるトラフィックの増加に応じ、自社のマーケットプレイスや課金周りのモノリシックだったシステムを従来のEC2ホストからKubernetesに移し、オートスケール機能を活用することと併せてコスト削減を実現することもできました

AppDirectのクラウドネイティブなスタックにはgRPC、Fluentdも含まれていて、そして今このチームはOpenCensusの立ち上げに取り組んでいるところです。このプラットフォームはすでにPrometheus で統合させているので、「どこかのチームがなんらかのサービスをデプロイするときには、通知、アラートやコンフィグ情報を受け取ることになります」とLacerteは言います。「たとえば、テスト環境ではSlackでメッセージが受け取れればいいですが、本番環境ではSlack メッセージと併せ呼び出しもしてもらいたいです。なので私たちはPagerDutyとのインテグレーションも行っています。サービスにおけるチームのオーナーシップが増していっているのです。」
-

AppDirectのクラウドネイティブなスタックにはgRPC、Fluentdも含まれていて、そして今このチームはOpenCensusの立ち上げに取り組んでいるところです。このプラットフォームはすでにPrometheus で統合させているので、「どこかのチームがなんらかのサービスをデプロイするときには、通知、アラートやコンフィグ情報を受け取ることになります」とLacerteは言います。「たとえば、テスト環境ではSlackでメッセージが受け取れればいいですが、本番環境ではSlack メッセージと併せ呼び出しもしてもらいたいです。なので私たちはPagerDutyとのインテグレーションも行っています。サービスにおけるチームのオーナーシップが増していっているのです。」

+
+
「私たちは、『ブランチにコードをプッシュする』だけのカルチャーから、コードベースを越えた、刺激的な新しい責務に移行しました。機能や設定のデプロイ、アプリケーションとビジネスメトリクスのモニタリング、そして機能停止が起きた場合の電話サポートなどがそれにあたります。それは計り知れないほどのエンジニアリング文化のシフトでしたが、規模とスピードを考えるとそのメリットは否定できません。」

- AppDirect ソフトウェア開発 ディレクター Pierre-Alexandre Lacerte
+
-{{< case-studies/quote author="AppDirect ソフトウェア開発 ディレクター Pierre-Alexandre Lacerte" >}} -「私たちは、『ブランチにコードをプッシュする』だけのカルチャーから、コードベースを越えた、刺激的な新しい責務に移行しました。機能や設定のデプロイ、アプリケーションとビジネスメトリクスのモニタリング、そして機能停止が起きた場合の電話サポートなどがそれにあたります。それは計り知れないほどのエンジニアリング文化のシフトでしたが、規模とスピードを考えるとそのメリットは否定できません。」 -{{< /case-studies/quote >}} - -

もちろんそれは、より多くの責任も意味しています。「私たちはエンジニアに視野を広げるように依頼しました」とGervaisは言います。「私たちは、『ブランチにコードをプッシュする』だけのカルチャーから、コードベースを越えた、刺激的な新しい責務へ移行しました。機能やコンフィグのデプロイ、アプリケーションとビジネスメトリクスのモニタリング、そして機能停止が起きた場合の電話サポートなどがそれにあたります。「それは計り知れないほどのエンジニアリング文化のシフトでしたが、規模とスピードを考えるとそのメリットは否定できません。」

- -

エンジニアリングのレベルが上がり続けるにつれて、プラットフォームチームは新たな課題を抱えることになります。Kubernetesプラットフォームが誰からでもアクセス可能で簡単に利用できる、それを確実にしていくことが求められるのです。「チームにより多くの人を追加したとき、彼らが効率的で生産的であり、プラットフォームの強化の仕方を知っていることを確実にするにはどうすればいいでしょうか？」とLacerteは問います。そのために、私たちにはエバンジェリストがいて、ドキュメントを用意して、いくつかのプロジェクトの事例を紹介できるようにしているのです。なので実際にデモをして、AMA(Ask Me Anything: 何でも聞いてほしい)セッションを設けるのです。私たちはたくさんの人からの関心を得るためにさまざまな戦略を試みています。」

- -

Kubernetesの3年半もの旅を振り返り、GervaisはAppDirectが「正しいタイミングで正しい判断ができた」と感じています。「Kubernetesとクラウドネイティブ技術は、いまやデファクトのエコシステムとみなされています。スケールアウトしていく中で直面する新たな難題に取り組むにはどこに注力すべきか、私たちはわかっています。このコミュニティはとても活発で、当社の優秀なチームをすばらしく補完してくれています。前進していくために私たちが注力すべきなのは、エコシステムから恩恵を受けながら、日々のオペレーションにビジネス的な付加価値を提供していくことでしょう。」

+
もちろんそれは、より多くの責任も意味しています。「私たちはエンジニアに視野を広げるように依頼しました」とGervaisは言います。「私たちは、『ブランチにコードをプッシュする』だけのカルチャーから、コードベースを越えた、刺激的な新しい責務へ移行しました。機能やコンフィグのデプロイ、アプリケーションとビジネスメトリクスのモニタリング、そして機能停止が起きた場合の電話サポートなどがそれにあたります。「それは計り知れないほどのエンジニアリング文化のシフトでしたが、規模とスピードを考えるとそのメリットは否定できません。」

エンジニアリングのレベルが上がり続けるにつれて、プラットフォームチームは新たな課題を抱えることになります。Kubernetesプラットフォームが誰からでもアクセス可能で簡単に利用できる、それを確実にしていくことが求められるのです。「チームにより多くの人を追加したとき、彼らが効率的で生産的であり、プラットフォームの強化の仕方を知っていることを確実にするにはどうすればいいでしょうか？」とLacerteは問います。そのために、私たちにはエバンジェリストがいて、ドキュメントを用意して、いくつかのプロジェクトの事例を紹介できるようにしているのです。なので実際にデモをして、AMA(Ask Me Anything: 何でも聞いてほしい)セッションを設けるのです。私たちはたくさんの人からの関心を得るためにさまざまな戦略を試みています。」

Kubernetesの3年半もの旅を振り返り、GervaisはAppDirectが「正しいタイミングで正しい判断ができた」と感じています。「Kubernetesとクラウドネイティブ技術は、いまやデファクトのエコシステムとみなされています。スケールアウトしていく中で直面する新たな難題に取り組むにはどこに注力すべきか、私たちはわかっています。このコミュニティはとても活発で、当社の優秀なチームをすばらしく補完してくれています。前進していくために私たちが注力すべきなのは、エコシステムから恩恵を受けながら、日々のオペレーションにビジネス的な付加価値を提供していくことでしょう。」
+
diff --git a/content/ja/case-studies/chinaunicom/index.html b/content/ja/case-studies/chinaunicom/index.html index 1f3fff3cee..4c288aa97a 100644 --- a/content/ja/case-studies/chinaunicom/index.html +++ b/content/ja/case-studies/chinaunicom/index.html @@ -1,78 +1,104 @@ --- -title: China Unicom ケーススタディ +title: China Unicom Case Study + linkTitle: chinaunicom case_study_styles: true cid: caseStudies -featured: false - -new_case_study_styles: true -heading_background: /images/case-studies/chinaunicom/banner1.jpg -heading_title_logo: /images/chinaunicom_logo.png -title_prefix: "ケーススタディ：" -subheading: > - Kubernetesが私たちのクラウドインフラの経験値を上げてくれました。今のところ、これに代わる技術はありません。 -case_study_details: - - 企業名: China Unicom - - 所在地: 中国、北京 - - 業界: テレコム +css: /css/style_case_studies.css +logo: chinaunicom_featured_logo.png +featured: true +weight: 1 +quote: > + Kubernetesが私たちのクラウドインフラの経験値を上げてくれました。今のところ、これに代わる技術はありません。 --- -

課題

+
+

ケーススタディ：
China Unicom社：KubernetesによるITコスト削減と効率性向上をいかにして実現したか
-

China Unicomは、中国でトップ3の通信事業者の1つであり、その3億人のユーザーにサービスを提供するために、2016年以来 VMWare、OpenStackのインフラやDockerによるコンテナ化を用い数千のサーバーのデータセンターを複数運用しています。残念なことに、「リソース使用率は相対的に低かった」と、プラットフォーム技術のR&D部門のグループリーダーであるChengyu Zhangは語っています。「そして、私たちには何百ものアプリケーションに収容できるクラウドプラットフォームがありませんでした。」以前は完全な国有企業だったChina Unicomは、近年BAT(Baidu、Alibaba、Tencent)およびJD.comからの民間投資を受け、いまや商用製品ではなくオープンソース技術を活用した社内開発にも注力しています。そこで、ZhangのChina Unicomの研究開発チームは、クラウドインフラ用のオープンソースオーケストレーションツールを探索し始めたのです。

+

-

ソリューション

+
-

急成長し、オープンソースコミュニティも成熟しているKubernetesはChina Unicomにとって自然な選択となりました。同社のKubernetes対応クラウドプラットフォームでは、現状の50のマイクロサービスに加え、これから新たに開発されるすべてをここでホストしていくそうです。「Kubernetesが私たちのクラウドインフラの経験値を上げてくれました」とZhangはいいます。「今のところ、これに代わる技術はありません。」また、China Unicomはそのマイクロサービスフレームワークのために、Istio、 Envoy、 CoreDNS、そしてFluentdも活用しています。

+
+ 企業名  China Unicom     所在地 中国、北京     業界 テレコム +
+
+
+
+
+

課題

+ China Unicomは、中国でトップ3の通信事業者の1つであり、その3億人のユーザーにサービスを提供するために、2016年以来 VMWare、OpenStackのインフラやDockerによるコンテナ化を用い数千のサーバーのデータセンターを複数運用しています。残念なことに、「リソース使用率は相対的に低かった」と、プラットフォーム技術のR&D部門のグループリーダーであるChengyu Zhangは語っています。「そして、私たちには何百ものアプリケーションに収容できるクラウドプラットフォームがありませんでした。」以前は完全な国有企業だったChina Unicomは、近年BAT(Baidu、Alibaba、Tencent)およびJD.comからの民間投資を受け、いまや商用製品ではなくオープンソース技術を活用した社内開発にも注力しています。そこで、ZhangのChina Unicomの研究開発チームは、クラウドインフラ用のオープンソースオーケストレーションツールを探索し始めたのです。 +

+ +

ソリューション

+ 急成長し、オープンソースコミュニティも成熟しているKubernetesはChina Unicomにとって自然な選択となりました。同社のKubernetes対応クラウドプラットフォームでは、現状の50のマイクロサービスに加え、これから新たに開発されるすべてをここでホストしていくそうです。「Kubernetesが私たちのクラウドインフラの経験値を上げてくれました」とZhangはいいます。「今のところ、これに代わる技術はありません。」また、China Unicomはそのマイクロサービスフレームワークのために、Istio、 Envoy、 CoreDNS、そしてFluentdも活用しています。 +

インパクト

+ KubernetesはChina Unicomの運用と開発、両方について効率を高めてくれました。 +リソース使用率は20〜50％上がり、ITインフラのコストも削減され、数時間かかっていたデプロイ時間は5〜10分にまで短縮されました。「こうすることができたのはおもに自己修復機能(self-healing)とスケーラビリティによるもので、これらによって私たちの運用や保守の効率を向上させることができるのです」とZhangは言います。「たとえば、私たちのシステムは今たった5人で保守されているのです。これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。 -

KubernetesはChina Unicomの運用と開発、両方について効率を高めてくれました。リソース使用率は20〜50％上がり、ITインフラのコストも削減され、数時間かかっていたデプロイ時間は5〜10分にまで短縮されました。「こうすることができたのはおもに自己修復機能(self-healing)とスケーラビリティによるもので、これらによって私たちの運用や保守の効率を向上させることができるのです」とZhangは言います。「たとえば、私たちのシステムは今たった5人で保守されているのです。これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。

+
-{{< case-studies/quote author="Chengyu Zhang、China Unicom プラットフォーム技術R&D グループリーダー" >}} -「Kubernetesが私達のクラウドインフラの経験値を上げてくれました。今のところ、これに代わる技術はありません。」 -{{< /case-studies/quote >}} +
+
+
+
+ 「Kubernetesが私達のクラウドインフラの経験値を上げてくれました。今のところ、これに代わる技術はありません。」 +
- Chengyu Zhang、 China Unicom プラットフォーム技術R&D グループリーダー +
+
+
+
+

China Unicomは、3億人を超えるユーザーを抱える、中国国内でトップ3の通信事業者の1つです。

-{{< case-studies/lead >}} -China Unicomは、3億人を超えるユーザーを抱える、中国国内でトップ3の通信事業者の1つです。 -{{< /case-studies/lead >}} + その舞台裏で、同社は2016年以来、Dockerコンテナ、VMware、OpenStackインフラなどを用いて、数千のサーバーを持つデータセンターを複数運用しています。残念ながら、「リソース利用率は相対的に低かった」と、プラットフォーム技術のR&D部門のグループリーダーであるChengyu Zhangは語っています。「そして、私たちには何百ものアプリケーションを収容できるクラウドプラットフォームがありませんでした。」 +

+ そこで新しい技術、研究開発(R&D)、およびプラットフォームの責務を担うZhangのチームは、IT管理におけるソリューションの探索を始めました。以前は完全な国営企業だったChina Unicomは、近年BAT(Baidu、Alibaba、Tencent)およびJD.comからの民間投資を受け、今は商用製品ではなくオープンソース技術を活用した社内開発に注力するようになりました。こういったこともあり、Zhangのチームはクラウドインフラのオープンソースオーケストレーションツールを探し始めたのです。 +
+
+
+
+ 「これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。」
- Chengyu Zhang、 China Unicom プラットフォーム技術R&D グループリーダー -

その舞台裏で、同社は2016年以来、Dockerコンテナ、VMware、OpenStackインフラなどを用いて、数千のサーバーを持つデータセンターを複数運用しています。残念ながら、「リソース利用率は相対的に低かった」と、プラットフォーム技術のR&D部門のグループリーダーであるChengyu Zhangは語っています。「そして、私たちには何百ものアプリケーションを収容できるクラウドプラットフォームがありませんでした。」

+
+
+
+
+ China Unicomはすでにコアとなる事業運用システムにMesosを活用していましたが、チームにとっては新しいクラウドプラットフォームにはKubernetesの選択が自然だろうと感じられたのです。「大きな理由は、Kubernetesには成熟したコミュニティがある、ということでした」とZhangは言います。「さらにKubernetesは非常に早いペースで成長していることもあり、さまざまな人のベストプラクティスから多くを学ぶことができるのです。」 またChina UnicomはマイクロサービスフレームワークのためにIstio、Envoy、CoreDNS、およびFluentdも使用しています。

-

そこで新しい技術、研究開発(R&D)、およびプラットフォームの責務を担うZhangのチームは、IT管理におけるソリューションの探索を始めました。以前は完全な国営企業だったChina Unicomは、近年BAT(Baidu、Alibaba、Tencent)およびJD.comからの民間投資を受け、今は商用製品ではなくオープンソース技術を活用した社内開発に注力するようになりました。こういったこともあり、Zhangのチームはクラウドインフラのオープンソースオーケストレーションツールを探し始めたのです。

+ 同社のKubernetes対応クラウドプラットフォームでは、現状の50のマイクロサービスに加え、これから新たに開発されるすべてをここでホストしていくそうです。China Unicomの開発者たちは自身の手による開発を省き、APIを介すことで簡単に技術が利用できるようになりました。このクラウドプラットフォームは、同社データセンタのPaaSプラットフォームに繋がった20〜30のサービスを提供することに加え、中国国内の31省にわたる拠点の社内ユーザーたちが行うビッグデータ分析などもサポートしています。

-{{< case-studies/quote - image="/images/case-studies/chinaunicom/banner3.jpg" - author="Chengyu Zhang、 China Unicom プラットフォーム技術R&D グループリーダー" ->}} -「これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。」 -{{< /case-studies/quote >}} + 「Kubernetesが私達のクラウドインフラの経験値を上げてくれました。」とZhangはいいます。「今のところ、これに代わる技術はありません。」 -

China Unicomはすでにコアとなる事業運用システムにMesosを活用していましたが、チームにとっては新しいクラウドプラットフォームにはKubernetesの選択が自然だろうと感じられたのです。「大きな理由は、Kubernetesには成熟したコミュニティがある、ということでした」とZhangは言います。「さらにKubernetesは非常に早いペースで成長していることもあり、さまざまな人のベストプラクティスから多くを学ぶことができるのです。」 またChina UnicomはマイクロサービスフレームワークのためにIstio、Envoy、CoreDNS、およびFluentdも使用しています。

+
+
+
+
+ 「この技術は比較的複雑ですが、開発者が慣れれば、恩恵をすべて享受できるのではないかと思います。」

- Jie Jia、China Unicom プラットフォーム技術 R&D +
+
-

同社のKubernetes対応クラウドプラットフォームでは、現状の50のマイクロサービスに加え、これから新たに開発されるすべてをここでホストしていくそうです。China Unicomの開発者たちは自身の手による開発を省き、APIを介すことで簡単に技術が利用できるようになりました。このクラウドプラットフォームは、同社データセンタのPaaSプラットフォームに繋がった20〜30のサービスを提供することに加え、中国国内の31省にわたる拠点の社内ユーザーたちが行うビッグデータ分析などもサポートしています。

+
+
+ 事実として、KubernetesはChina Unicomの運用と開発、両方について効率を高めてくれました。リソース使用率は20〜50％上がり、ITインフラのコストも削減され、数時間かかっていたデプロイ時間は5〜10分にまで短縮されました。「こうすることができたのはおもに自己修復機能(self-healing)とスケーラビリティによるもので、これらによって私たちの運用や保守の効率を向上させることができるのです」とZhangは言います。「たとえば、私たちのシステムは今たったの5人で保守されているのです。」

+ China UnicomにおけるKubernetesでの成功体験から、Zhangと彼のチームはコミュニティに積極的に貢献するようになりました。それは、Meetupやカンファレンスに参加したり、同じ道のりを歩むことを検討している他の企業にアドバイスを提供したりすることから始まりました。「とくに、トラディショナルなクラウドコンピューティング システムを保有してきた企業には、クラウドネイティブコンピューティングのコミュニティに参加することを本当にお勧めします」とZhangは言います。 +
-

「Kubernetesが私達のクラウドインフラの経験値を上げてくれました。」とZhangはいいます。「今のところ、これに代わる技術はありません。」

+
+
+「企業はRancherのような事業者が提供するマネージドサービスを活用することができます。こうした技術はすでにカスタマイズされて提供されるので、簡単に利用することができるでしょう。」

- Jie Jia、China Unicom プラットフォーム技術 R&D
+
-{{< case-studies/quote - image="/images/case-studies/chinaunicom/banner4.jpg" - author="Jie Jia、China Unicom プラットフォーム技術 R&D" ->}} -「この技術は比較的複雑ですが、開発者が慣れれば、恩恵をすべて享受できるのではないかと思います。」 -{{< /case-studies/quote >}} +
+ プラットフォーム技術 R&D チームの一員であるJie Jiaは、「この技術は比較的複雑ですが、開発者が慣れれば、恩恵をすべて享受できるのではないかと思います」と付け加えています。一方でZhangは、仮想マシンベースのクラウドでの経験から見ると、「Kubernetesとこれらのクラウドネイティブ技術は比較的シンプルなのではないか」と指摘しています。

+ 「企業は Rancher のような事業者が提供するマネージドサービスを活用することができます。こうした技術はカスタマイズされて提供されるので、簡単に利用することができるでしょう。」

-

事実として、KubernetesはChina Unicomの運用と開発、両方について効率を高めてくれました。リソース使用率は20〜50％上がり、ITインフラのコストも削減され、数時間かかっていたデプロイ時間は5〜10分にまで短縮されました。「こうすることができたのはおもに自己修復機能(self-healing)とスケーラビリティによるもので、これらによって私たちの運用や保守の効率を向上させることができるのです」とZhangは言います。「たとえば、私たちのシステムは今たったの5人で保守されているのです。」

+ 今後China Unicomはビッグデータと機械学習に重点を置いて、Kubernetes上でより多くのアプリケーションを開発することを計画しています。彼らのチームは築き上げたクラウドプラットフォームを継続的に最適化しており、CNCFの認定Kubernetesコンフォーマンスプログラム(Certified Kubernetes Conformance Program)に参加するべく、そのための適合テスト(Conformance test)への合格を目指しています。また彼らは、どこかのタイミングでコミュニティにコードをコントリビューションすることも目指しています。

-

China UnicomにおけるKubernetesでの成功体験から、Zhangと彼のチームはコミュニティに積極的に貢献するようになりました。それは、Meetupやカンファレンスに参加したり、同じ道のりを歩むことを検討している他の企業にアドバイスを提供したりすることから始まりました。「とくに、トラディショナルなクラウドコンピューティング システムを保有してきた企業には、クラウドネイティブコンピューティングのコミュニティに参加することを本当にお勧めします」とZhangは言います。

+ それが意欲的な発言と聞こえるのは、彼らがKubernetesを採用することで得た結果が彼らの期待していた最大値をも超えていたからでしょう。Zhangは次のように言います。「これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。」 -{{< case-studies/quote author="Jie Jia、China Unicom プラットフォーム技術 R&D" >}} -「企業はRancherのような事業者が提供するマネージドサービスを活用することができます。こうした技術はすでにカスタマイズされて提供されるので、簡単に利用することができるでしょう。」 -{{< /case-studies/quote >}} - -

プラットフォーム技術 R&D チームの一員であるJie Jiaは、「この技術は比較的複雑ですが、開発者が慣れれば、恩恵をすべて享受できるのではないかと思います」と付け加えています。一方でZhangは、仮想マシンベースのクラウドでの経験から見ると、「Kubernetesとこれらのクラウドネイティブ技術は比較的シンプルなのではないか」と指摘しています。

- -

「企業は Rancher のような事業者が提供するマネージドサービスを活用することができます。こうした技術はカスタマイズされて提供されるので、簡単に利用することができるでしょう。」

- -

今後China Unicomはビッグデータと機械学習に重点を置いて、Kubernetes上でより多くのアプリケーションを開発することを計画しています。彼らのチームは築き上げたクラウドプラットフォームを継続的に最適化しており、CNCFの認定Kubernetesコンフォーマンスプログラム(Certified Kubernetes Conformance Program)に参加するべく、そのための適合テスト(Conformance test)への合格を目指しています。また彼らは、どこかのタイミングでコミュニティにコードをコントリビューションすることも目指しています。

- -

それが意欲的な発言と聞こえるのは、彼らがKubernetesを採用することで得た結果が彼らの期待していた最大値をも超えていたからでしょう。Zhangは次のように言います。「これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。」

+
+
+ + diff --git a/content/ja/case-studies/nav/index.html b/content/ja/case-studies/nav/index.html index 1c1f34c78e..c9ad5ab65b 100644 --- a/content/ja/case-studies/nav/index.html +++ b/content/ja/case-studies/nav/index.html @@ -1,82 +1,93 @@ --- -title: Nav ケーススタディ +title: Navケーススタディ linkTitle: Nav case_study_styles: true cid: caseStudies -featured: false +css: /css/style_case_studies.css +logo: nav_featured_logo.png +featured: true +weight: 3 quote: > - コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています。 - -new_case_study_styles: true -heading_background: /images/case-studies/nav/banner1.jpg -heading_title_logo: /images/nav_logo.png -title_prefix: "ケーススタディ：" -subheading: > - スタートアップはどのようにしてKubernetesでインフラコストを50％も削減したのか -case_study_details: - - 企業名: Nav - - 所在地: ユタ州ソルトレイクシティ、カリフォルニア州サンマテオ - - 業界: 事業者向け金融サービス + コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています。 --- -

課題

+
+

ケーススタディ：
スタートアップはどのようにしてKubernetesでインフラコストを50％も削減したのか

-

2012年に設立された Navは、小規模事業者たちに、民間信用調査企業主要3社 —Equifax、Experian、Dun＆Bradstreet— におけるビジネス信用スコアと、彼らのニーズに最適な資金調達オプションを提供しています。このスタートアップは5年で急速に成長したことで、「クラウド環境が非常に大きくなっていったのですが、これらの環境の使用率は極端に低く、1％を下回っていました」とエンジニアリングディレクターのTravis Jeppsonは述べています。「クラウド環境の使用率と実際私たちに必要なものとを連動させたかったので、同じリソースプールを共有しながら複数のワークロードそれぞれを分離して実行できるコンテナ化やオーケストレーションを検討しました。」

+
+
+ 企業名  Nav     所在地  ユタ州ソルトレイクシティ、カリフォルニア州サンマテオ     業界  事業者向け金融サービス +
+ +
+
+
+
+

+

課題

+2012年に設立された Navは、小規模事業者たちに、民間信用調査企業主要3社 —Equifax、Experian、Dun＆Bradstreet— におけるビジネス信用スコアと、彼らのニーズに最適な資金調達オプションを提供しています。このスタートアップは5年で急速に成長したことで、「クラウド環境が非常に大きくなっていったのですが、これらの環境の使用率は極端に低く、1％を下回っていました」とエンジニアリングディレクターのTravis Jeppsonは述べています。「クラウド環境の使用率と実際私たちに必要なものとを連動させたかったので、同じリソースプールを共有しながら複数のワークロードそれぞれを分離して実行できるコンテナ化やオーケストレーションを検討しました。」 +

ソリューション

- -

数多くのオーケストレーション ソリューションを評価した結果、Navチームは AWS上で稼働する Kubernetesを採用することを決めました。Kubernetesを取り巻くコミュニティの強みは人を引きつける点にあり、それがGoogleから生まれたものであることもその一つです。加えて、「他のソリューションは、かなり手間がかかり、本当に複雑で大きなものでした。そしてすぐに管理できるかという点においても厳しいものになりがちでした」とJeppsonは言います。「Kubernetesはその当時の私たちのニーズに合ったオーケストレーションソリューションに踏み出せる、とてもシンプルなやり方を提供してくれました。さらにその拡張性は、私たちがKubernetesと共に成長し、その後の追加機能を組み入れることを可能にしてくれました。」

+数多くのオーケストレーション ソリューションを評価した結果、Navチームは AWS上で稼働する Kubernetesを採用することを決めました。Kubernetesを取り巻くコミュニティの強みは人を引きつける点にあり、それがGoogleから生まれたものであることもその一つです。加えて、「他のソリューションは、かなり手間がかかり、本当に複雑で大きなものでした。そしてすぐに管理できるかという点においても厳しいものになりがちでした」とJeppsonは言います。「Kubernetesはその当時の私たちのニーズに合ったオーケストレーションソリューションに踏み出せる、とてもシンプルなやり方を提供してくれました。さらにその拡張性は、私たちがKubernetesと共に成長し、その後の追加機能を組み入れることを可能にしてくれました。」

インパクト

+4人編成のチームは、6か月でKubernetesを稼働させ、その後の6ヶ月でNavの25あったマイクロサービスすべてのマイグレーションを完了させました。その結果は目覚しいものでした。導入のきっかけとなったリソース使用率については、1％から40％まで増加しました。かつて新しいサービスを立ち上げるのに2人の開発者が2週間かけていましたが、いまや開発者はたった一人で10分もかかりません。デプロイ数は5倍増えました。そして同社はインフラコストを50％削減しています。 -

4人編成のチームは、6か月でKubernetesを稼働させ、その後の6ヶ月でNavの25あったマイクロサービスすべてのマイグレーションを完了させました。その結果は目覚しいものでした。導入のきっかけとなったリソース使用率については、1％から40％まで増加しました。かつて新しいサービスを立ち上げるのに2人の開発者が2週間かけていましたが、いまや開発者はたった一人で10分もかかりません。デプロイ数は5倍増えました。そして同社はインフラコストを50％削減しています。

+
+
+
-{{< case-studies/quote author="Travis Jeppson、Nav エンジニアリング ディレクター" >}} - -
+
+
+ +

「Kubernetesはその当時の私たちのニーズに合ったオーケストレーションソリューションに踏み出せる、とてもシンプルなやり方を提供してくれました。さらにその拡張性は、私たちがKubernetesと共に成長し、その後の追加機能を組み入れることを可能にしてくれました。」 -{{< /case-studies/quote >}} +

- Travis Jeppson、Nav エンジニアリング ディレクター
+
+
+
+

2012年に設立された Navは、小規模事業者たちに、民間信用調査企業主要3社 —Equifax、Experian、Dun＆Bradstreet— におけるビジネス信用スコアと、彼らのニーズに最適な資金調達オプションを提供しています。「スモールビジネスの成功率を上げていくこと。」そのミッションはここに凝縮される、とエンジニアリングディレクターのTravis Jeppsonは言います。

+数年前、Navは自分たちの成功への道筋に、障害があることを認識しました。ビジネスが急速に成長し、「クラウド環境が非常に大きくなっていったのですが、これらの環境の使用率は極端に低く、1％を下回っていました」と、Jeppsonは言います。「問題の大部分はスケールに関するものでした。私たちはそこにただお金を投入しようとしていました。『もっと多くのサーバーを稼働させよう。増えた負荷をさばくためにより多く作業しよう』といった具合に。私たちはスタートアップなので、そんなことをしていては終焉の一途をたどりかねませんし、そんなことにに使えるほどお金の余裕は我々にはないのです。」 +

+ こういったことに加えてすべての新サービスは違う10人を経由してリリースされなければならず、サービス立ち上げに2週間という受け入れがたいほどの時間をかけていたのです。パッチ管理とサーバ管理のすべてが手動で行われていたので、皆がそれらを見守り、うまく維持していく必要があったのです」とJeppsonは付け加えます。「非常にやっかいなシステムでした。」 -{{< case-studies/lead >}} -2012年に設立された Navは、小規模事業者たちに、民間信用調査企業主要3社 —Equifax、Experian、Dun＆Bradstreet— におけるビジネス信用スコアと、彼らのニーズに最適な資金調達オプションを提供しています。「スモールビジネスの成功率を上げていくこと。」そのミッションはここに凝縮される、とエンジニアリングディレクターのTravis Jeppsonは言います。 -{{< /case-studies/lead >}} +
+
+
+
「コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています。」

- Travis Jeppson、Nav エンジニアリングディレクター
-

数年前、Navは自分たちの成功への道筋に、障害があることを認識しました。ビジネスが急速に成長し、「クラウド環境が非常に大きくなっていったのですが、これらの環境の使用率は極端に低く、1％を下回っていました」と、Jeppsonは言います。「問題の大部分はスケールに関するものでした。私たちはそこにただお金を投入しようとしていました。『もっと多くのサーバーを稼働させよう。増えた負荷をさばくためにより多く作業しよう』といった具合に。私たちはスタートアップなので、そんなことをしていては終焉の一途をたどりかねませんし、そんなことにに使えるほどお金の余裕は我々にはないのです。」

-

こういったことに加えてすべての新サービスは違う10人を経由してリリースされなければならず、サービス立ち上げに2週間という受け入れがたいほどの時間をかけていたのです。パッチ管理とサーバ管理のすべてが手動で行われていたので、皆がそれらを見守り、うまく維持していく必要があったのです」とJeppsonは付け加えます。「非常にやっかいなシステムでした。」

+
+
+
Jeppsonは前職でコンテナを取り扱っていたため、Navの経営陣にこれらの問題の解決策としてこの技術を売り込みました。そして2017年初め彼の提案にゴーサインがでました。「クラウド環境の使用率と実際私たちに必要なものとを連動させたかったので、類似したリソースプールを共有しながら複数のワークロードそれぞれを分離して実行できるコンテナ化やオーケストレーションを検討しました」と、彼は言います。

+ 数多くのオーケストレーションソリューションを評価した結果、Navチームは AWSでのKubernetes 採用を決断しました。Kubernetesを取り巻くコミュニティの強みは人を引きつける点にあり、それがGoogleから生まれたものであることもその一つです。加えて、「他のソリューションは、かなり手間がかかり、本当に複雑で大きなものでした。そしてすぐに管理できるかという点においても厳しいものになりがちでした」とJeppsonは言います。「Kubernetesはその当時の私たちのニーズに合ったオーケストレーションソリューションに踏み出せる、とてもシンプルなやり方を提供してくれました。一方でその拡張性は、私たちがKubernetesと共に成長し、その後の追加機能を組み入れることを可能にしてくれました。」

+ Jeppsonの4人編成のエンジニアリングサービスチームは、Kubernetesを立ち上げ、稼働させるのに6ヶ月かけました（クラスターを動かすために Kubespray を使いました）。そして、その後6ヶ月かけNavの25のマイクロサービスと一つのモノリシックな主要サービスのフルマイグレーションを完了させました。「すべて書き換えたり、止めることはできませんでした」と彼は言います。「稼働し、利用可能であり続けなければいけなかったですし、ダウンタイムがあってもをそれを最小にしなければなりませんでした。そのためパイプライン作成、メトリクスやロギングといったことについてよくわかるようになりました。さらにKubernetes自身についても習熟し、起動、アップグレード、サービス提供の仕方についてもわかるようになりました。そうして移行を少しずつ進めていきました。」 +
+
+
+
+「Kubernetesは、これまで経験したことのない新たな自由とたくさんの価値をNavにもたらしてくれました。」

- Travis Jeppson、Nav エンジニアリングディレクター +
+
-{{< case-studies/quote - image="/images/case-studies/nav/banner3.jpg" - author="Travis Jeppson、Nav エンジニアリングディレクター" ->}} -「コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています。」 -{{< /case-studies/quote >}} +
-

Jeppsonは前職でコンテナを取り扱っていたため、Navの経営陣にこれらの問題の解決策としてこの技術を売り込みました。そして2017年初め彼の提案にゴーサインがでました。「クラウド環境の使用率と実際私たちに必要なものとを連動させたかったので、類似したリソースプールを共有しながら複数のワークロードそれぞれを分離して実行できるコンテナ化やオーケストレーションを検討しました」と、彼は言います。

+
+この過程で重要だったのは、Navの50人のエンジニアを教育すること、そしてマイグレーションに当たり新たなワークフローやロードマップについて透明性を確保することでした。 +そこでJeppsonはエンジニアリングスタッフ全員に対し定期的なプレゼンテーションや、一週間にわたる1日4時間の実習の場を設けました。そして彼はすべての情報を置いておくために GitLabにリポジトリを作成しました。 「フロントエンドとバックエンドの開発者たち全員に、kubectlを用い、独力でnamespaceを作成し、取り扱う方法を見せていきました」と彼は言います。「いまや、彼らはやってきて『これは準備OKだ』というだけで済むことが多くなりました。GitLabの小さなボタンをクリックすれば本番環境にリリースできるようになっているので彼らはすぐに次の行動に移ることができます。」

+ マイグレーションが2018年初めに完了したあとの結果は目覚しいものでした。導入のきっかけとなったリソース使用率については、1％から40％まで増加しました。かつて新しいサービスを立ち上げるのに2人の開発者が2週間かけていましたが、いまや開発者はたった一人で10分もかかりません。デプロイ数は1日あたり10だったものから50となり5倍増えました。そして同社はインフラコストを50％削減しています。「次はデータベース側に取り組みたいです。それができればかなりのコスト削減を継続できるでしょう」とJeppsonは言います。

+ また、KubernetesはNavのコンプライアンスのニーズにも力を貸しました。以前は、「1つのアプリケーションを1つのサーバーにマッピングする必要がありました。これは主にデータ周辺でコンプライアンスの異なるレギュレーションがあったためです」とJeppsonは言います。「KubernetesのAPIを用いれば、ネットワークポリシーを追加し、必要に応じてそれらのデータを分離し制限をかけることができるようになります。」同社は、クラスターを規制のないゾーンと、独自ノードセットを持ったデータ保護を行うべき規制ゾーンに分離しています。また、Twistlockツールを使用することでセキュリティを確保しています。「夜、よく眠れることもね」と彼は付け加えます。 +
-

数多くのオーケストレーションソリューションを評価した結果、Navチームは AWSでのKubernetes 採用を決断しました。Kubernetesを取り巻くコミュニティの強みは人を引きつける点にあり、それがGoogleから生まれたものであることもその一つです。加えて、「他のソリューションは、かなり手間がかかり、本当に複雑で大きなものでした。そしてすぐに管理できるかという点においても厳しいものになりがちでした」とJeppsonは言います。「Kubernetesはその当時の私たちのニーズに合ったオーケストレーションソリューションに踏み出せる、とてもシンプルなやり方を提供してくれました。一方でその拡張性は、私たちがKubernetesと共に成長し、その後の追加機能を組み入れることを可能にしてくれました。」

+
+
「今私たちが扱っているトラフィック量の4〜10倍が流れたとしても、『ああ、大丈夫だよ、Kubernetesがやってくれるから』と話しています。」

- Travis Jeppson、Nav エンジニアリング ディレクター
+
-

Jeppsonの4人編成のエンジニアリングサービスチームは、Kubernetesを立ち上げ、稼働させるのに6ヶ月かけました（クラスターを動かすために Kubespray を使いました）。そして、その後6ヶ月かけNavの25のマイクロサービスと一つのモノリシックな主要サービスのフルマイグレーションを完了させました。「すべて書き換えたり、止めることはできませんでした」と彼は言います。「稼働し、利用可能であり続けなければいけなかったですし、ダウンタイムがあってもをそれを最小にしなければなりませんでした。そのためパイプライン作成、メトリクスやロギングといったことについてよくわかるようになりました。さらにKubernetes自身についても習熟し、起動、アップグレード、サービス提供の仕方についてもわかるようになりました。そうして移行を少しずつ進めていきました。」

+
+ Kubernetesが導入された中、Navチームは Prometheusを採用してシステムのメトリクスやロギングの改良も始めました。。「Prometheusは開発者にとって、とても採用しやすいメトリクスの標準を作ってくれました」とJeppsonは言います。「彼らには、何をしたいかを示し、したいことを実践し、そして彼らのコードベースをクリーンな状態に保つ自由があります。そして私たちにとってそれはまちがいなく必須事項でした。」

+ これから先を見据え、次にNavが意欲的に視野に入れているのは、トレーシング(Tracing)、ストレージ、そしてサービスメッシュです。そしてKubeConで多くの時間をいろんな企業との対話に費やしたその後で、現在彼らはEnvoy、 OpenTracing、そして Jaegerを検証しています。「コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています」とJeppsonは言います。「クラウドネイティブなソリューションをフルに採用できるようになるには、スケーラビリティ面でやるべきことがまだたくさんあります。」

+ もちろん、すべてはKubernetesから始まります。Jeppsonのチームは、この技術でNavをスケール可能にするプラットフォームを構築しました。そして「これまで経験したことのない新たな自由、たくさんの価値をNavにもたらしてくれたのです。」と彼は言います。新製品を検討しようにも、隔離された環境を用意するのに6か月待たなければならず、その後もトラフィックが急上昇するのに対応するやりかたも考え出さなければならないという事実があり、身動きが取れなくなってしまっていました。「しかし、もうそういった話もなくなりました。」とJeppsonは言います。「今私たちが扱っているトラフィック量の4〜10倍が流れたとしても、『ああ、大丈夫だよ、Kubernetesがやってくれるから』と話しています。」 -{{< case-studies/quote - image="/images/case-studies/nav/banner4.jpg" - author="Travis Jeppson、Nav エンジニアリングディレクター" ->}} -「Kubernetesは、これまで経験したことのない新たな自由とたくさんの価値をNavにもたらしてくれました。」 -{{< /case-studies/quote >}} - -

この過程で重要だったのは、Navの50人のエンジニアを教育すること、そしてマイグレーションに当たり新たなワークフローやロードマップについて透明性を確保することでした。そこでJeppsonはエンジニアリングスタッフ全員に対し定期的なプレゼンテーションや、一週間にわたる1日4時間の実習の場を設けました。そして彼はすべての情報を置いておくために GitLabにリポジトリを作成しました。 「フロントエンドとバックエンドの開発者たち全員に、kubectlを用い、独力でnamespaceを作成し、取り扱う方法を見せていきました」と彼は言います。「いまや、彼らはやってきて『これは準備OKだ』というだけで済むことが多くなりました。GitLabの小さなボタンをクリックすれば本番環境にリリースできるようになっているので彼らはすぐに次の行動に移ることができます。」

- -

マイグレーションが2018年初めに完了したあとの結果は目覚しいものでした。導入のきっかけとなったリソース使用率については、1％から40％まで増加しました。かつて新しいサービスを立ち上げるのに2人の開発者が2週間かけていましたが、いまや開発者はたった一人で10分もかかりません。デプロイ数は1日あたり10だったものから50となり5倍増えました。そして同社はインフラコストを50％削減しています。「次はデータベース側に取り組みたいです。それができればかなりのコスト削減を継続できるでしょう」とJeppsonは言います。

- -

また、KubernetesはNavのコンプライアンスのニーズにも力を貸しました。以前は、「1つのアプリケーションを1つのサーバーにマッピングする必要がありました。これは主にデータ周辺でコンプライアンスの異なるレギュレーションがあったためです」とJeppsonは言います。「KubernetesのAPIを用いれば、ネットワークポリシーを追加し、必要に応じてそれらのデータを分離し制限をかけることができるようになります。」同社は、クラスターを規制のないゾーンと、独自ノードセットを持ったデータ保護を行うべき規制ゾーンに分離しています。また、Twistlockツールを使用することでセキュリティを確保しています。「夜、よく眠れることもね」と彼は付け加えます。

- -{{< case-studies/quote author="Travis Jeppson、Nav エンジニアリング ディレクター" >}} -「今私たちが扱っているトラフィック量の4〜10倍が流れたとしても、『ああ、大丈夫だよ、Kubernetesがやってくれるから』と話しています。」 -{{< /case-studies/quote >}} - -

Kubernetesが導入された中、Navチームは Prometheusを採用してシステムのメトリクスやロギングの改良も始めました。。「Prometheusは開発者にとって、とても採用しやすいメトリクスの標準を作ってくれました」とJeppsonは言います。「彼らには、何をしたいかを示し、したいことを実践し、そして彼らのコードベースをクリーンな状態に保つ自由があります。そして私たちにとってそれはまちがいなく必須事項でした。」

- -

これから先を見据え、次にNavが意欲的に視野に入れているのは、トレーシング(Tracing)、ストレージ、そしてサービスメッシュです。そしてKubeConで多くの時間をいろんな企業との対話に費やしたその後で、現在彼らはEnvoy、 OpenTracing、そして Jaegerを検証しています。「コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています」とJeppsonは言います。「クラウドネイティブなソリューションをフルに採用できるようになるには、スケーラビリティ面でやるべきことがまだたくさんあります。」

- -

もちろん、すべてはKubernetesから始まります。Jeppsonのチームは、この技術でNavをスケール可能にするプラットフォームを構築しました。そして「これまで経験したことのない新たな自由、たくさんの価値をNavにもたらしてくれたのです。」と彼は言います。新製品を検討しようにも、隔離された環境を用意するのに6か月待たなければならず、その後もトラフィックが急上昇するのに対応するやりかたも考え出さなければならないという事実があり、身動きが取れなくなってしまっていました。「しかし、もうそういった話もなくなりました。」とJeppsonは言います。「今私たちが扱っているトラフィック量の4〜10倍が流れたとしても、『ああ、大丈夫だよ、Kubernetesがやってくれるから』と話しています。」

+
+
diff --git a/content/ja/case-studies/nordstrom/index.html b/content/ja/case-studies/nordstrom/index.html index ec757ca23c..e867f49d7c 100644 --- a/content/ja/case-studies/nordstrom/index.html +++ b/content/ja/case-studies/nordstrom/index.html @@ -2,76 +2,105 @@ title: Nordstrom ケーススタディ case_study_styles: true cid: caseStudies - -new_case_study_styles: true -heading_background: /images/case-studies/nordstrom/banner1.jpg -heading_title_logo: /images/nordstrom_logo.png -title_prefix: "ケーススタディ：" -subheading: > - 厳しい小売環境下で数百万ドルのコスト削減を実現 -case_study_details: - - 企業名: Nordstrom - - 所在地: シアトル、ワシントン - - 業界: 小売り +css: /css/style_case_studies.css --- -

課題

- -

NordstromはECサイトのNordstrom.comを含む技術的な運用の効率と速度を向上させたいと考えていました。同時に、Nordstrom Technologyでは技術的な運用コストを抑える方法を模索していました。

- -

解決策

- -

4年前にDevOpsを採用し、CI/CD(継続的インテグレーション/継続的デプロイ)プロジェクトを開始した後、同社はデプロイ時間を3か月から30分に短縮しました。ですが、環境間でさらに高速化するために、KubernetesでオーケストレーションされたDockerコンテナを採用しました。

- -

影響

- -

Kubernetesを使用するNordstrom Technologyの開発者はより迅速にデプロイし、「アプリケーションを書くことだけに集中できる」と、NordstromのKubernetesエンタープライズプラットフォーム構築チームのシニアエンジニアであるDhawal Patel氏は言います。チームはOpsの効率を向上させ、ワークロードに応じてCPU使用率を5倍から12倍改善しました。「私たちは何千もの仮想マシンを実行していますが、これらのリソースをすべて効率的に使用できているわけではありません。」とPatel氏は語ります。「Kubernetes を採用することで、クラスターの効率化に挑戦することなく以前の10倍効率化できています。」

- -{{< case-studies/quote author="Nordstrom社シニアエンジニア Dhawal Patel" >}} -私たちは常に、技術の最適化を通じてより大きな価値を提供する方法を探しています。Kubernetesを用いて私たちは開発効率と運用効率という2つの効率を示します。これは双方にとって好都合です。 -{{< /case-studies/quote >}} - -

5年前にDhawal Patelが小売業者のウェブサイトのアプリケーション開発者としてNordstromに入社したとき、彼は開発サイクルをスピードアップする機会があることに気づきました。

- -

DevOpsの初期の頃、Nordstrom Technologyは従来のサイロチームと機能モデルを引き続き採用していました。「開発者として、コードの記述やビジネスへの価値の追加よりも環境の修正に多くの時間を費やしました。」とPatel氏は言います。「私はそれについて情熱的だったので、修正する機会を与えられました。」

- -

同社はまた、より早く行動することに熱心であり、2013年に最初の継続的インテグレーション/継続的デプロイ(CI/CD)プロジェクトを開始しました。このプロジェクトはNordstromのクラウドネイティブへの旅の第一歩でした。

- -

開発チームと運用チームのメンバーは社内のオンプレミスサーバーを使ってCI/CDパイプラインを構築しました。チームはChefを選択し、仮想IPの作成、サーバー、および負荷分散を自動化したクックブックを作成しました。「プロジェクトの完了後、デプロイにかかる時間は3か月から30分になりました。」とPatal氏は言います。「開発環境、テスト環境、ステージング環境、本番環境という複数環境があったため、各環境でChefクックブックを流すのに30分かかりました。その時点で大きな成果でした。」

- -

しかし、新しい環境はまだ立ち上がるのに時間がかかりすぎていたため、次のステップはクラウドでの作業でした。現在、Nordstrom Technologyはエンタープライズプラットフォームを構築しており、同社の1,500名の開発者はKubernetesでオーケストレーションされたDockerコンテナとして動作するアプリケーションをクラウド上にデプロイできるようになりました。

- -{{< case-studies/quote image="/images/case-studies/nordstrom/banner3.jpg" >}} -「私たちはKubernetesに人気が出ることに賭けました。コミュニティのサポートとプロジェクトの速度の初期の指標に基づいて、Kubernetesを中心にシステムを再構築しました。」 -{{< /case-studies/quote >}} - -

「オンプレミスで仮想マシン(VM)を取得するのに数週間かかったため、クラウドはリソースへの高速なアクセスを提供しました。」とPatal氏は言います。「しかし、今ではたった5分で同じことができます。」

- -

Nordstromがクラスター上のコンテナのスケジューリングに初めて進出したのはCoreOS fleetベースの自社開発のシステムでした。彼らは、Kubernetesに切り替えるときに、Kubernetes 1.0がリリースされるまでそのシステムでいくつかのPoCプロジェクトを始めました。「コミュニティのサポートとプロジェクトの速度の初期の指標に基づき、Kubernetesの人気が出るだろうと確信したため、Kubernetesを中心にシステムを再構築しました。」とNordstromのKubernetesチームのシニアマネージャーMarius Grigoriuは述べます。

- -

Kubernetesは多くの場合、マイクロサービスのプラットフォームと考えられていますが、NordstromにおいてKubernetesで始動した最初の重要なプロダクションの役割を担うアプリケーションはJiraでした。「最初のアプリケーションとして期待していた理想的なマイクロサービスではありませんでした。」とPatal氏は認めます。「しかし、それに取り組んでいたチームは本当にDockerとKubernetesに情熱を傾けており、実際に使いたいと考えていました。彼らは自社運用のアプリケーションをオンプレミスで実行しており、それをKubernetesに移行したいと考えていました。」

- -

参加したチームにとってメリットはすぐに現れました。「Kubernetesクラスターを使っているチームは心配する問題が少ないという事実を気に入っていました。インフラストラクチャーやオペレーティングシステムを管理する必要はありませんでした。」とGrigoriu氏は言います。「初期の導入者は、Kubernetesの宣言的な性質を好んでいます。彼らは対処しなければならなかった領域が減少したことを好んでます。」

- -{{< case-studies/quote image="/images/case-studies/nordstrom/banner4.jpg">}} -「Kubernetesクラスターを使っているチームは心配する問題が少ないという事実を気に入っていました。インフラストラクチャーやオペレーティングシステムを管理する必要はありませんでした。」とGrigoriu氏は言います。「初期の導入者は、Kubernetesの宣言的な性質を好んでいます。彼らは対処しなければならなかった領域が減少したことを好んでます。」 -{{< /case-studies/quote >}} +
+

ケーススタディ:
厳しい小売環境下で数百万ドルのコスト削減を実現 -

これらの初期の導入者をサポートするため、Patelのチームはクラスターの成長とプロダクションレベルのサービスの構築を開始しました。「私たちは監視のためのPrometheusとGrafanaフロントエンドを組み合わせました。また、Fluentdを使用してログをElasticsearchにプッシュしたため、ログの集約が可能になりました。」とPatel氏は語ります。チームはまたCNCFプロジェクトを含む多数のオープンソースコンポーネントを追加し、Kubernetes、Terraformおよびkube2iamに貢献しました。

+

-

現在、Nordstrom TechnologyにはKubernetesを使っている開発チームは60以上あり、成功事例が出てくるにつれて、より多くのチームが参加するようになりました。「これを試してみようと思った最初の顧客基盤は次のユーザに勧め始めています。」Patel氏は言います。「初期の導入者の1人はDockerコンテナを使用しており、本番環境での実行方法がわかりませんでした。私たちは彼と一緒に座って、15分以内に本番環境に展開しました。彼はそれが素晴らしいと思い、彼の組織のより多くの人々が加わり始めました。」

+
-

Nordstrom Technologyの場合、クラウドネイティブへの移行によって、開発と運用の効率が大幅に向上しています。Kubernetesを利用する開発者はより迅速にデプロイでき、アプリケーションの価値の構築に専念できます。こうしたノウハウを取り入れるために、1つのチームにおいてクラウド上に仮想マシンを構築し、マージからデプロイまでに25分かかるところからスタートしました。Kubernetesへの切り替えにより、プロセスが5倍高速化され、マージからデプロイまでの時間が5分に改善しました。

+
+ 企業名  Nordstrom     所在地  シアトル、ワシントン     業界  小売り +
-{{< case-studies/quote >}} -「Kubernetesを使用することで、クラスタの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」 -{{< /case-studies/quote >}} +
+
+
+
+

課題

+ NordstromはECサイトのNordstrom.comを含む技術的な運用の効率と速度を向上させたいと考えていました。同時に、Nordstrom Technologyでは技術的な運用コストを抑える方法を模索していました。 +
+

解決策

+ 4年前にDevOpsを採用し、CI/CD(継続的インテグレーション/継続的デプロイ)プロジェクトを開始した後、同社はデプロイ時間を3か月から30分に短縮しました。ですが、環境間でさらに高速化するために、KubernetesでオーケストレーションされたDockerコンテナを採用しました。 +
-

スピードは素晴らしく、簡単に実証できますが、より大きな影響はおそらくその運用効率にあります。「AWSで何千ものVMを実行する場合、全体的な平均CPU使用率は約4%です。」とPatel氏は言います。「Kubernetesを使用することで、クラスタの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」

-

Nordstrom TechnologyはオンプレミスのベアメタルでKubernetesを実行することも検討しています。Patel氏は言います。「オンプレミスのKubernetesクラスターを構築できれば、クラウドの力を活用してオンプレミスでリソースを迅速にプロビジョニングできます。次に、開発者にとってのインターフェースはKubernetesです。Kubernetesのみと連携しているため、自社のサービスがオンプレミスにデプロイされていることに気付かないこともあります。」

+
-

そのため、Patel氏はKubernetesのマルチクラスター機能の開発に熱心に取り組んでいます。「クラスターフェデレーションにより、オンプレミスをプライマリクラスターとして、クラウドをセカンダリバースト可能なクラスターとして使用できます。」と彼は言います。「つまり、アニバーサリーセールやブラックフライデーセールがあり、さらにコンテナが必要な場合は、クラウドにアクセスできます。」

+
-

この種の可能性とGrigoriuとPatelのチームがKubernetesを使用してすでに提供しているという反響が、Nordstromをそもそもクラウドネイティブジャーニーに導いた理由です。「現在の小売環境は、可能な限り即応性と柔軟性を高めようとしています。」とGrigoriu氏は言います。「Kubernetesにより、開発側と運用側の両方にとってバランスよく効率化されます。これは双方にとって好都合です。」

+

影響

+ Kubernetesを使用するNordstrom Technologyの開発者はより迅速にデプロイし、「アプリケーションを書くことだけに集中できる」と、NordstromのKubernetesエンタープライズプラットフォーム構築チームのシニアエンジニアであるDhawal Patel氏は言います。チームはOpsの効率を向上させ、ワークロードに応じてCPU使用率を5倍から12倍改善しました。「私たちは何千もの仮想マシンを実行していますが、これらのリソースをすべて効率的に使用できているわけではありません。」とPatel氏は語ります。「Kubernetes を採用することで、クラスターの効率化に挑戦することなく以前の10倍効率化できています。」 +
+
+
+
+
+ 私たちは常に、技術の最適化を通じてより大きな価値を提供する方法を探しています。Kubernetesを用いて私たちは開発効率と運用効率という2つの効率を示します。これは双方にとって好都合です。 +

-Nordstrom社シニアエンジニア Dhawal Patel +
+
+
+
+ 5年前にDhawal Patelが小売業者のウェブサイトのアプリケーション開発者としてNordstromに入社したとき、彼は開発サイクルをスピードアップする機会があることに気づきました。 +

+ DevOpsの初期の頃、Nordstrom Technologyは従来のサイロチームと機能モデルを引き続き採用していました。「開発者として、コードの記述やビジネスへの価値の追加よりも環境の修正に多くの時間を費やしました。」とPatel氏は言います。「私はそれについて情熱的だったので、修正する機会を与えられました。」 +

+ 同社はまた、より早く行動することに熱心であり、2013年に最初の継続的インテグレーション/継続的デプロイ(CI/CD)プロジェクトを開始しました。このプロジェクトはNordstromのクラウドネイティブへの旅の第一歩でした。 +

+ 開発チームと運用チームのメンバーは社内のオンプレミスサーバーを使ってCI/CDパイプラインを構築しました。チームはChefを選択し、仮想IPの作成、サーバー、および負荷分散を自動化したクックブックを作成しました。「プロジェクトの完了後、デプロイにかかる時間は3か月から30分になりました。」とPatal氏は言います。「開発環境、テスト環境、ステージング環境、本番環境という複数環境があったため、各環境でChefクックブックを流すのに30分かかりました。その時点で大きな成果でした。」 +

しかし、新しい環境はまだ立ち上がるのに時間がかかりすぎていたため、次のステップはクラウドでの作業でした。現在、Nordstrom Technologyはエンタープライズプラットフォームを構築しており、同社の1,500名の開発者はKubernetesでオーケストレーションされたDockerコンテナとして動作するアプリケーションをクラウド上にデプロイできるようになりました。 + +
+
+
+
+ 「私たちはKubernetesに人気が出ることに賭けました。コミュニティのサポートとプロジェクトの速度の初期の指標に基づいて、Kubernetesを中心にシステムを再構築しました。」 +
+
+
+
+ +「オンプレミスで仮想マシン(VM)を取得するのに数週間かかったため、クラウドはリソースへの高速なアクセスを提供しました。」とPatal氏は言います。「しかし、今ではたった5分で同じことができます。」 +

+Nordstromがクラスター上のコンテナのスケジューリングに初めて進出したのはCoreOS fleetベースの自社開発のシステムでした。彼らは、Kubernetesに切り替えるときに、Kubernetes 1.0がリリースされるまでそのシステムでいくつかのPoCプロジェクトを始めました。「コミュニティのサポートとプロジェクトの速度の初期の指標に基づき、Kubernetesの人気が出るだろうと確信したため、Kubernetesを中心にシステムを再構築しました。」とNordstromのKubernetesチームのシニアマネージャーMarius Grigoriuは述べます。 +Kubernetesは多くの場合、マイクロサービスのプラットフォームと考えられていますが、NordstromにおいてKubernetesで始動した最初の重要なプロダクションの役割を担うアプリケーションはJiraでした。「最初のアプリケーションとして期待していた理想的なマイクロサービスではありませんでした。」とPatal氏は認めます。「しかし、それに取り組んでいたチームは本当にDockerとKubernetesに情熱を傾けており、実際に使いたいと考えていました。彼らは自社運用のアプリケーションをオンプレミスで実行しており、それをKubernetesに移行したいと考えていました。」 +

+参加したチームにとってメリットはすぐに現れました。「Kubernetesクラスターを使っているチームは心配する問題が少ないという事実を気に入っていました。インフラストラクチャーやオペレーティングシステムを管理する必要はありませんでした。」とGrigoriu氏は言います。「初期の導入者は、Kubernetesの宣言的な性質を好んでいます。彼らは対処しなければならなかった領域が減少したことを好んでます。」 +
+
+
+
+ 「Kubernetesクラスターを使っているチームは心配する問題が少ないという事実を気に入っていました。インフラストラクチャーやオペレーティングシステムを管理する必要はありませんでした。」とGrigoriu氏は言います。「初期の導入者は、Kubernetesの宣言的な性質を好んでいます。彼らは対処しなければならなかった領域が減少したことを好んでます。」 +
+
+ +
+
+ これらの初期の導入者をサポートするため、Patelのチームはクラスターの成長とプロダクションレベルのサービスの構築を開始しました。「私たちは監視のためのPrometheusとGrafanaフロントエンドを組み合わせました。また、Fluentdを使用してログをElasticsearchにプッシュしたため、ログの集約が可能になりました。」とPatel氏は語ります。チームはまたCNCFプロジェクトを含む多数のオープンソースコンポーネントを追加し、Kubernetes、Terraformおよびkube2iamに貢献しました。 +

+現在、Nordstrom TechnologyにはKubernetesを使っている開発チームは60以上あり、成功事例が出てくるにつれて、より多くのチームが参加するようになりました。「これを試してみようと思った最初の顧客基盤は次のユーザに勧め始めています。」Patel氏は言います。「初期の導入者の1人はDockerコンテナを使用しており、本番環境での実行方法がわかりませんでした。私たちは彼と一緒に座って、15分以内に本番環境に展開しました。彼はそれが素晴らしいと思い、彼の組織のより多くの人々が加わり始めました。」 +

+Nordstrom Technologyの場合、クラウドネイティブへの移行によって、開発と運用の効率が大幅に向上しています。Kubernetesを利用する開発者はより迅速にデプロイでき、アプリケーションの価値の構築に専念できます。こうしたノウハウを取り入れるために、1つのチームにおいてクラウド上に仮想マシンを構築し、マージからデプロイまでに25分かかるところからスタートしました。Kubernetesへの切り替えにより、プロセスが5倍高速化され、マージからデプロイまでの時間が5分に改善しました。 +
+ +
+
+ 「Kubernetesを使用することで、クラスタの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」 +
+
+ +
+ スピードは素晴らしく、簡単に実証できますが、より大きな影響はおそらくその運用効率にあります。「AWSで何千ものVMを実行する場合、全体的な平均CPU使用率は約4%です。」とPatel氏は言います。「Kubernetesを使用することで、クラスタの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」 +

+ Nordstrom TechnologyはオンプレミスのベアメタルでKubernetesを実行することも検討しています。Patel氏は言います。「オンプレミスのKubernetesクラスターを構築できれば、クラウドの力を活用してオンプレミスでリソースを迅速にプロビジョニングできます。次に、開発者にとってのインターフェースはKubernetesです。Kubernetesのみと連携しているため、自社のサービスがオンプレミスにデプロイされていることに気付かないこともあります。」 + そのため、Patel氏はKubernetesのマルチクラスター機能の開発に熱心に取り組んでいます。「クラスターフェデレーションにより、オンプレミスをプライマリクラスターとして、クラウドをセカンダリバースト可能なクラスターとして使用できます。」と彼は言います。「つまり、アニバーサリーセールやブラックフライデーセールがあり、さらにコンテナが必要な場合は、クラウドにアクセスできます。」 +

+ この種の可能性とGrigoriuとPatelのチームがKubernetesを使用してすでに提供しているという反響が、Nordstromをそもそもクラウドネイティブジャーニーに導いた理由です。「現在の小売環境は、可能な限り即応性と柔軟性を高めようとしています。」とGrigoriu氏は言います。「Kubernetesにより、開発側と運用側の両方にとってバランスよく効率化されます。これは双方にとって好都合です。」 + +
+
diff --git a/content/ja/case-studies/sos/index.html b/content/ja/case-studies/sos/index.html index c63fa4ab51..814e9cb119 100644 --- a/content/ja/case-studies/sos/index.html +++ b/content/ja/case-studies/sos/index.html @@ -3,82 +3,108 @@ title: SOS International ケーススタディ linkTitle: SOS International case_study_styles: true cid: caseStudies +css: /css/style_case_studies.css logo: sos_featured_logo.png - -new_case_study_styles: true -heading_background: /images/case-studies/sos/banner1.jpg -heading_title_logo: /images/sos_logo.png -title_prefix: "ケーススタディ：" -subheading: > - SOS International: Kubernetesを使ってコネクテッドな世界での緊急支援を提供 -case_study_details: - - 企業名: SOS International - - 所在地: フレゼレクスベア、デンマーク - - 業界: 医療および旅行支援 --- -

課題

-

SOS Internationalは60年にわたり、北欧諸国の顧客に信頼性の高い緊急医療および旅行支援を提供してきました。近年、同社のビジネス戦略では、デジタル分野での開発をさらに強化する必要がありましたが、ITシステムに関しては3つの従来のモノリス(Java, .NET, およびIBMのAS/400)とウォーターフォールアプローチにおいて「SOSには非常に断片化された遺産があります。」とエンタープライズアーキテクチャ責任者のMartin Ahrentsen氏は言います。「新しい技術と新しい働き方の両方を導入することを余儀なくされているので、市場投入までの時間を短縮して効率を高めることができました。それははるかに機敏なアプローチであり、私たちにはそれをビジネスに提供するのに役立つプラットフォームが必要でした。」

+
+

ケーススタディ:
SOS International: Kubernetesを使ってコネクテッドな世界での緊急支援を提供 -

ソリューション

+

-

標準システムの模索に失敗した後、同社はプラットフォームアプローチを採用し、Kubernetesとコンテナ技術を包含するソリューションを探すことにしました。RedHat OpenShiftはSOSの断片化されたシステムに最適であることが証明されました。「私たちはコード言語とその他の両方を使用する多くの異なる技術を持っていますが、それらはすべて新しいプラットフォーム上のリソースを使用できます。」とAhrentsen氏は言います。同社にある3つのモノリスの中で、「2つ(.NETとJava)に対してこの最先端の技術を提供できます。」このプラットフォームは2018年春に公開されました。現在、マイクロサービスアーキテクチャに基づく6つの未開発プロジェクトが進行中であり、さらに、同社のJavaアプリケーションはすべて「リフト&シフト」移行を行っています。

+
+
+ 企業名  SOS International     所在地  フレゼレクスベア、デンマーク +     業界  医療および旅行支援 +
+ +
+
+
+
+

課題

+ SOS Internationalは60年にわたり、北欧諸国の顧客に信頼性の高い緊急医療および旅行支援を提供してきました。近年、同社のビジネス戦略では、デジタル分野での開発をさらに強化する必要がありましたが、ITシステムに関しては +3つの従来のモノリス(Java, .NET, およびIBMのAS/400)とウォーターフォールアプローチにおいて「SOSには非常に断片化された遺産があります。」とエンタープライズアーキテクチャ責任者のMartin Ahrentsen氏は言います。「新しい技術と新しい働き方の両方を導入することを余儀なくされているので、市場投入までの時間を短縮して効率を高めることができました。それははるかに機敏なアプローチであり、私たちにはそれをビジネスに提供するのに役立つプラットフォームが必要でした。」 + + +

+

ソリューション

+ 標準システムの模索に失敗した後、同社はプラットフォームアプローチを採用し、Kubernetesとコンテナ技術を包含するソリューションを探すことにしました。RedHat OpenShiftはSOSの断片化されたシステムに最適であることが証明されました。「私たちはコード言語とその他の両方を使用する多くの異なる技術を持っていますが、それらはすべて新しいプラットフォーム上のリソースを使用できます。」とAhrentsen氏は言います。同社にある3つのモノリスの中で、「2つ(.NETとJava)に対してこの最先端の技術を提供できます。」このプラットフォームは2018年春に公開されました。現在、マイクロサービスアーキテクチャに基づく6つの未開発プロジェクトが進行中であり、さらに、同社のJavaアプリケーションはすべて「リフト&シフト」移行を行っています。 +

影響

+ Kubernetesによって「市場投入までの時間、アジリティ、および変更と新しい技術に適応する能力の向上を実現しました。」とAhrentsen氏は語ります。「ソフトウェアのリリース準備ができてからリリースできるまでの時間が大幅に改善されました。」SOS Internationalの考え方も劇的に変わりました。「自動化、CI/CDパイプラインの作成を容易にするKubernetesとスクリプトへの簡単なアクセスがあるので、この完全自動化の方法に至る所で多くの内部的な関心が生まれています。旅を始めるために非常に良い気候を作り出しています。」と彼は言います。さらに、クラウドネイティブのコミュニティの一員であることは、同社が人材を引き付けるのに役立ちました。「彼らはクールで新しい技術を使いたいと思っています」とAhrentsen氏は言います。「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」 +
-

Kubernetesによって「市場投入までの時間、アジリティ、および変更と新しい技術に適応する能力の向上を実現しました。」とAhrentsen氏は語ります。「ソフトウェアのリリース準備ができてからリリースできるまでの時間が大幅に改善されました。」SOS Internationalの考え方も劇的に変わりました。「自動化、CI/CDパイプラインの作成を容易にするKubernetesとスクリプトへの簡単なアクセスがあるので、この完全自動化の方法に至る所で多くの内部的な関心が生まれています。旅を始めるために非常に良い気候を作り出しています。」と彼は言います。さらに、クラウドネイティブのコミュニティの一員であることは、同社が人材を引き付けるのに役立ちました。「彼らはクールで新しい技術を使いたいと思っています」とAhrentsen氏は言います。「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」

+
+
+
+
+ 「クラウドネイティブなソフトウェアや技術が現在推進している変化の速度は驚くべきものであり、それに追従して導入することは私たちにとって非常に重要です。Kubernetesとクラウドネイティブが提供する驚くべき技術はデジタルの未来に向けてSOSに変化をもたらしました。 +

- SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen +
+
+
+
+

SOS Internationalは60年にわたり、北欧諸国の顧客に信頼性の高い緊急医療および旅行支援を提供してきました。

+ SOSのオペレータは年間100万件の案件を扱い、100万件以上の電話を処理しています。しかし、過去4年間で同社のビジネス戦略にデジタル空間でのますます激しい開発が必要になりました。

+ ITシステムに関していえば、会社のデータセンターで稼働する3つの伝統的なモノリスとウォーターフォールアプローチにおいて「SOSは非常に断片化された資産があります。」とエンタープライズアーキテクチャ責任者のMartin Ahrentsen氏は言います。「市場投入までの時間を短縮し、効率を高めるために新しい技術と新しい働き方の両方を導入する必要がありました。それははるかに機敏なアプローチであり、それをビジネスに提供するために役立つプラットフォームが必要でした。」 +

+ Ahrentsen氏と彼のチームは長い間SOSで機能する標準のソリューションを探していました。「私たちのような支援会社はそれほど多くないので、それにふさわしい標準システムを入手することはできません。完全に一致するものがないのです。」と彼は言います。「標準システムを採用したとしても、あまりにもひねりすぎて、もはや標準ではないものになるでしょう。そのため、新しいデジタルシステムとコアシステムを構築するために使用できるいくつかの共通コンポーネントを備えた技術プラットフォームを見つけることにしました。」 -{{< case-studies/quote author="SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen" >}} -「クラウドネイティブなソフトウェアや技術が現在推進している変化の速度は驚くべきものであり、それに追従して導入することは私たちにとって非常に重要です。Kubernetesとクラウドネイティブが提供する驚くべき技術はデジタルの未来に向けてSOSに変化をもたらしました。」 -{{< /case-studies/quote >}} -{{< case-studies/lead >}} -SOS Internationalは60年にわたり、北欧諸国の顧客に信頼性の高い緊急医療および旅行支援を提供してきました。 -{{< /case-studies/lead >}} +
+
+
+
+ 「私たちは新しいデジタルサービスを提供しなければなりませんが、古いものも移行する必要があります。そして、コアシステムをこのプラットフォーム上に構築された新しいシステムに変換する必要があります。この技術を選んだ理由の1つは古いデジタルサービスを変更しながら新しいサービスを構築できるからです。」 -

SOSのオペレータは年間100万件の案件を扱い、100万件以上の電話を処理しています。しかし、過去4年間で同社のビジネス戦略にデジタル空間でのますます激しい開発が必要になりました。

+

- SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen -

ITシステムに関していえば、会社のデータセンターで稼働する3つの伝統的なモノリスとウォーターフォールアプローチにおいて「SOSは非常に断片化された資産があります。」とエンタープライズアーキテクチャ責任者のMartin Ahrentsen氏は言います。「市場投入までの時間を短縮し、効率を高めるために新しい技術と新しい働き方の両方を導入する必要がありました。それははるかに機敏なアプローチであり、それをビジネスに提供するために役立つプラットフォームが必要でした。」

+
+
+
+
+ Kubernetesができることを理解すると、Ahrentsen氏はすぐにビジネスニーズを満たすことができるプラットフォームに目を向けました。同社はDockerコンテナとKubernetesを組み込んだRed HatのOpenShift Container Platformを採用しました。また、RedHat Hyperconverged Infrastructureや一部のミッドウェアコンポーネントなど、すべてオープンソースコミュニティで提供されている技術スタックも利用することを決めました。

-

Ahrentsen氏と彼のチームは長い間SOSで機能する標準のソリューションを探していました。「私たちのような支援会社はそれほど多くないので、それにふさわしい標準システムを入手することはできません。完全に一致するものがないのです。」と彼は言います。「標準システムを採用したとしても、あまりにもひねりすぎて、もはや標準ではないものになるでしょう。そのため、新しいデジタルシステムとコアシステムを構築するために使用できるいくつかの共通コンポーネントを備えた技術プラットフォームを見つけることにしました。」

+ 技術やアジリティの適合性、法的要件、およびコンピテンシーという同社の基準に基づくと、OpenShiftソリューションはSOSの断片化されたシステムに完全に適合するように思われました。「私たちはコード言語とそれ以外の両方を使用する多くの異なる技術を持っています。それらはすべて新しいプラットフォーム上のリソースを使用できます。」とAhrentsen氏は言います。同社にある3つのモノリスの中で、「2つ(.NETとJava)に対してこの最先端の技術を提供できます。」

-{{< case-studies/quote - image="/images/case-studies/sos/banner3.jpg" - author="SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen" ->}} -「私たちは新しいデジタルサービスを提供しなければなりませんが、古いものも移行する必要があります。そして、コアシステムをこのプラットフォーム上に構築された新しいシステムに変換する必要があります。この技術を選んだ理由の1つは古いデジタルサービスを変更しながら新しいサービスを構築できるからです。」 -{{< /case-studies/quote >}} +プラットフォームは2018年春に公開されました。マイクロサービスアーキテクチャに基づく6つの未開発のプロジェクトが最初に開始されました。さらに、同社のJavaアプリケーションはすべて「リフト&シフト」移行を行っています。最初に稼働しているKubernetesベースのプロジェクトの一つがRemote Medical Treatmentです。これは顧客が音声、チャット、ビデオを介してSOSアラームセンターに連絡できるソリューションです。「完全なCI/CDパイプラインと最新のマイクロサービスアーキテクチャをすべて2つのOpenShiftクラスターセットアップで実行することに焦点を当てて、非常に短時間で開発できました。」とAhrentsen氏は言います。北欧諸国へのレスキュートラックの派遣に使用されるOnsite、および、レッカー車の追跡を可能にするFollow Your Truckも展開されています。 +
+
+
+
+ 「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」 +

- SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen +
+
-

Kubernetesができることを理解すると、Ahrentsen氏はすぐにビジネスニーズを満たすことができるプラットフォームに目を向けました。同社はDockerコンテナとKubernetesを組み込んだRed HatのOpenShift Container Platformを採用しました。また、RedHat Hyperconverged Infrastructureや一部のミッドウェアコンポーネントなど、すべてオープンソースコミュニティで提供されている技術スタックも利用することを決めました。

+
+
+ プラットフォームがまだオンプレミスで稼働しているのは、保険業界のSOSの顧客の一部は同社がデータを処理しているためまだクラウド戦略を持っていないためです。KubernetesはSOSがデータセンターで開始し、ビジネスの準備ができたらクラウドに移行できるようにします。「今後3～5年にわたって、彼らすべてが戦略を持ち、そして、データを取り出してクラウドに移行できるでしょう。」とAhrentsen氏は言います。機密データと非機密データのハイブリッドクラウド設定に移行する可能性もあります。

-

技術やアジリティの適合性、法的要件、およびコンピテンシーという同社の基準に基づくと、OpenShiftソリューションはSOSの断片化されたシステムに完全に適合するように思われました。「私たちはコード言語とそれ以外の両方を使用する多くの異なる技術を持っています。それらはすべて新しいプラットフォーム上のリソースを使用できます。」とAhrentsen氏は言います。同社にある3つのモノリスの中で、「2つ(.NETとJava)に対してこの最先端の技術を提供できます。」

+ SOSの技術は確かに過渡期にあります。「新しいデジタルサービスを提供する必要がありますが、古いものも移行する必要があり、コアシステムをこのプラットフォーム上に構築された新しいシステムに変換しなければなりません。」とAhrentsen氏は言います。「この技術を選んだ理由の1つは古いデジタルサービスを変更しながら新しいサービスを構築できるからです。」

-

プラットフォームは2018年春に公開されました。マイクロサービスアーキテクチャに基づく6つの未開発のプロジェクトが最初に開始されました。さらに、同社のJavaアプリケーションはすべて「リフト&シフト」移行を行っています。最初に稼働しているKubernetesベースのプロジェクトの一つがRemote Medical Treatmentです。これは顧客が音声、チャット、ビデオを介してSOSアラームセンターに連絡できるソリューションです。「完全なCI/CDパイプラインと最新のマイクロサービスアーキテクチャをすべて2つのOpenShiftクラスターセットアップで実行することに焦点を当てて、非常に短時間で開発できました。」とAhrentsen氏は言います。北欧諸国へのレスキュートラックの派遣に使用されるOnsite、および、レッカー車の追跡を可能にするFollow Your Truckも展開されています。

+ しかし、Kubernetesはすでに市場投入までの時間を短縮しており、そのことは、新興プロジェクトがいかに迅速に開発され、リリースされたかにも表れています。「ソフトウェアのリリース準備ができてからリリース可能になるまでの時間は劇的に改善されました。」とAhrentsen氏は言います。

-{{< case-studies/quote - image="/images/case-studies/sos/banner4.jpg" - author="SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen" ->}} -「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」 -{{< /case-studies/quote >}} + さらに、クラウドネイティブのコミュニティの一員であることは、エンジニア、オペレーター、アーキテクトの数を今年60から100に増やすという目標を追求するうえで、同社が人材を引き付けるのに役立ちました。「彼らはクールで新しい技術を使いたいと思っています。」とAhrentsenは言います。「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」 -

プラットフォームがまだオンプレミスで稼働しているのは、保険業界のSOSの顧客の一部は同社がデータを処理しているためまだクラウド戦略を持っていないためです。KubernetesはSOSがデータセンターで開始し、ビジネスの準備ができたらクラウドに移行できるようにします。「今後3～5年にわたって、彼らすべてが戦略を持ち、そして、データを取り出してクラウドに移行できるでしょう。」とAhrentsen氏は言います。機密データと非機密データのハイブリッドクラウド設定に移行する可能性もあります。

+
-

SOSの技術は確かに過渡期にあります。「新しいデジタルサービスを提供する必要がありますが、古いものも移行する必要があり、コアシステムをこのプラットフォーム上に構築された新しいシステムに変換しなければなりません。」とAhrentsen氏は言います。「この技術を選んだ理由の1つは古いデジタルサービスを変更しながら新しいサービスを構築できるからです。」

+
+
+ 「すべてが接続され、データを送信する未来の世界は、新しい市場機会という点で私たちにとって大きな可能性を生み出します。しかし、それはまたITプラットフォームと私たちが提供すべきものに大きな需要をもたらすでしょう。」 +

- SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen
+
-

しかし、Kubernetesはすでに市場投入までの時間を短縮しており、そのことは、新興プロジェクトがいかに迅速に開発され、リリースされたかにも表れています。「ソフトウェアのリリース準備ができてからリリース可能になるまでの時間は劇的に改善されました。」とAhrentsen氏は言います。

+
+ SOS Internationalの考え方も劇的に変わりました。「自動化、CI/CDパイプラインの作成を容易にするKubernetesとスクリプトへの簡単なアクセスがあるので、この完全自動化の方法に至る所で多くの内部的な関心が生まれています。旅を始めるために非常に良い気候を作り出しています。」

-

さらに、クラウドネイティブのコミュニティの一員であることは、エンジニア、オペレーター、アーキテクトの数を今年60から100に増やすという目標を追求するうえで、同社が人材を引き付けるのに役立ちました。「彼らはクールで新しい技術を使いたいと思っています。」とAhrentsenは言います。「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」

+ SOSにおけるこの旅では、デジタル化と最適化がキーワードです。「ITがこれを実現するには改善する必要がありますが、それはKubernetesとプラットフォームの使用方法だけではありません。」とAhrentsen氏は言います。「これは自動化、そしてその後の機械学習やその他進行中の興味深い技術の準備が整ったシステムを構築する方法でもあります。」

-{{< case-studies/quote author="SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen" >}} -「すべてが接続され、データを送信する未来の世界は、新しい市場機会という点で私たちにとって大きな可能性を生み出します。しかし、それはまたITプラットフォームと私たちが提供すべきものに大きな需要をもたらすでしょう。」 -{{< /case-studies/quote >}} + 代表例：自動車へのIoTの導入。欧州委員会は現在、すべての新車にeCallを装備することを義務づけています。eCallは重大な交通事故が発生した場合に位置やその他データを送信します。SOSはこのサービスをスマート自動支援として提供しています。「電話を受けて、緊急対応チームを派遣する必要があるかどうか、またはそれほど大きな影響がないどうかを確認します。」とAhrentsen氏は言います。「すべてが接続され、データを送信する未来の世界は、新しい市場機会という点で私たちにとって大きな可能性を生み出します。しかし、それはまたITプラットフォームと私たちが提供すべきものに大きな需要をもたらすでしょう。」

-

SOS Internationalの考え方も劇的に変わりました。「自動化、CI/CDパイプラインの作成を容易にするKubernetesとスクリプトへの簡単なアクセスがあるので、この完全自動化の方法に至る所で多くの内部的な関心が生まれています。旅を始めるために非常に良い気候を作り出しています。」

- -

SOSにおけるこの旅では、デジタル化と最適化がキーワードです。「ITがこれを実現するには改善する必要がありますが、それはKubernetesとプラットフォームの使用方法だけではありません。」とAhrentsen氏は言います。「これは自動化、そしてその後の機械学習やその他進行中の興味深い技術の準備が整ったシステムを構築する方法でもあります。」

- -

代表例：自動車へのIoTの導入。欧州委員会は現在、すべての新車にeCallを装備することを義務づけています。eCallは重大な交通事故が発生した場合に位置やその他データを送信します。SOSはこのサービスをスマート自動支援として提供しています。「電話を受けて、緊急対応チームを派遣する必要があるかどうか、またはそれほど大きな影響がないどうかを確認します。」とAhrentsen氏は言います。「すべてが接続され、データを送信する未来の世界は、新しい市場機会という点で私たちにとって大きな可能性を生み出します。しかし、それはまたITプラットフォームと私たちが提供すべきものに大きな需要をもたらすでしょう。」

- -

Ahrentsen氏はSOSが技術の選択を行ってきたことを考えると、この課題に十分対応できると感じています。「クラウドネイティブなソフトウェアや技術が現在推進している変化の速度は驚くべきものであり、それに追従して採用することは私たちにとって非常に重要です。」と彼は言います。「Kubernetesとクラウドネイティブが提供する驚くべき技術は、デジタルの未来に向けてSOSに変化をもたらし始めました。」

+ Ahrentsen氏はSOSが技術の選択を行ってきたことを考えると、この課題に十分対応できると感じています。「クラウドネイティブなソフトウェアや技術が現在推進している変化の速度は驚くべきものであり、それに追従して採用することは私たちにとって非常に重要です。」と彼は言います。「Kubernetesとクラウドネイティブが提供する驚くべき技術は、デジタルの未来に向けてSOSに変化をもたらし始めました。」 +
+
diff --git a/content/ja/case-studies/spotify/index.html b/content/ja/case-studies/spotify/index.html index 09a82b5fdb..0725723b68 100644 --- a/content/ja/case-studies/spotify/index.html +++ b/content/ja/case-studies/spotify/index.html @@ -1,82 +1,120 @@ --- -title: Spotify ケーススタディ -linkTitle: Spotify +title: Spotifyケーススタディ +linkTitle: Spotify case_study_styles: true cid: caseStudies -featured: false +css: /css/style_case_studies.css +logo: spotify_featured_logo.png +featured: true +weight: 2 quote: > - Kubernetesを中心に成長した素晴らしいコミュニティを見て、その一部になりたかったのです。スピードの向上とコスト削減のメリットを享受し、ベストプラクティスとツールについて業界の他の企業と連携したいとも思いました。 - -new_case_study_styles: true -heading_background: /images/case-studies/spotify/banner1.jpg -heading_title_text: Spotify -title_prefix: "ケーススタディ：" -subheading: > - Spotify：コンテナ技術のアーリーアダプターであるSpotifyは自社製オーケストレーションツールからKubernetesに移行しています -case_study_details: - - 企業名: Spotify - - 所在地: グローバル - - 業界: エンターテイメント + Kubernetesを中心に成長した素晴らしいコミュニティを見て、その一部になりたかったのです。スピードの向上とコスト削減のメリットを享受し、ベストプラクティスとツールについて業界の他の企業と連携したいとも思いました。 --- -

課題

+
+

ケーススタディ：Spotify
Spotify：コンテナ技術のアーリーアダプターであるSpotifyは自社製オーケストレーションツールからKubernetesに移行しています -

2008年から始まったオーディオストリーミングプラットフォームは、アクティブユーザーが世界中で毎月2億人を超えるまでに成長しました。「私たちの目標は、クリエイターたちに力を与え、私たちが現在抱えるすべての消費者、そして願わくば将来抱える消費者が真に没入できる音楽体験を実現することです」、エンジニアリング、インフラおよびオペレーション担当ディレクターのJai Chakrabartiは、こう言います。マイクロサービスとDockerのアーリーアダプターであるSpotifyは、Heliosという自社開発のコンテナオーケストレーションシステムを使い、自社のVM全体にわたり実行されるマイクロサービスをコンテナ化していました。2017年末までには、「こういった機能開発に自社の小さなチームで取り組むことは効率的ではなく、大きなコミュニティで支持されているものを採用したほうがよい」ことがはっきりしてきました。

+

-

ソリューション

+
-

「Kubernetesを中心に成長した素晴らしいコミュニティを見て、その一部になりたかったのです。」とChakrabartiは言います。KubernetesはHeliosよりも豊富な機能を有していました。さらに、「スピードの向上とコスト削減のメリットを享受し、ベストプラクティスとツールについて業界の他の企業と連携したいとも思いました。」また彼のチームは、活発なKubernetesコミュニティにその知見でコントリビュートし、影響を与えることも望みました。Heliosの稼働と並行して行われたマイグレーションは、スムーズにすすめることができました。それは「KubernetesがHeliosを補完するものとして、そして今はHeliosを代替するものとして非常にフィットしたものだったからです」とChakrabartiは言います。

+
+ 企業名  Spotify     所在地  グローバル     業界  エンターテイメント +
+ +
+
+
+
+

課題

+ 2008年から始まったオーディオストリーミングプラットフォームは、アクティブユーザーが世界中で毎月2億人を超えるまでに成長しました。「私たちの目標は、クリエイターたちに力を与え、私たちが現在抱えるすべての消費者、そして願わくば将来抱える消費者が真に没入できる音楽体験を実現することです」、エンジニアリング、インフラおよびオペレーション担当ディレクターのJai Chakrabartiは、こう言います。マイクロサービスとDockerのアーリーアダプターであるSpotifyは、Heliosという自社開発のコンテナオーケストレーションシステムを使い、自社のVM全体にわたり実行されるマイクロサービスをコンテナ化していました。2017年末までには、「こういった機能開発に自社の小さなチームで取り組むことは効率的ではなく、大きなコミュニティで支持されているものを採用したほうがよい」ことがはっきりしてきました。 + +

+

ソリューション

+ 「Kubernetesを中心に成長した素晴らしいコミュニティを見て、その一部になりたかったのです。」とChakrabartiは言います。KubernetesはHeliosよりも豊富な機能を有していました。さらに、「スピードの向上とコスト削減のメリットを享受し、ベストプラクティスとツールについて業界の他の企業と連携したいとも思いました。」また彼のチームは、活発なKubernetesコミュニティにその知見でコントリビュートし、影響を与えることも望みました。Heliosの稼働と並行して行われたマイグレーションは、スムーズにすすめることができました。それは「KubernetesがHeliosを補完するものとして、そして今はHeliosを代替するものとして非常にフィットしたものだったからです」とChakrabartiは言います。

インパクト

+ 2018年の後半に始まり、2019年に向けて大きな注力点となる本マイグレーションにおいて必要となる主要な技術の問題に対応するため、チームは2018年の大半を費やしました。「ほんの一部をKubernetesに移行したのですが、社内チームから聞こえてきたのは、手作業でのキャパシティプロビジョニングを意識する必要性が少なくなり、Spotifyとしての機能の提供に集中できる時間がより多くなってきたということです」とChakrabartiは言います。Kubernetesで現在実行されている最も大きなサービスはアグリゲーションサービスで、1秒あたり約1000万リクエストを受け取り、オートスケールによる大きな恩恵を受けている、とサイト・リライアビリティ・エンジニアのJames Wenは言います。さらに、「以前はチームが新しいサービスを作り、運用ホストを本番環境で稼働させるために1時間待たなければなりませんでしたが、Kubernetesでは秒・分のオーダーでそれを実現できます」と付け加えます。さらに、Kubernetesのビンパッキング（組み合わせ最適化）機能やマルチテナント機能により、CPU使用率が平均して2〜3倍向上しました。 + +
+
+
+
+
+ 「Kubernetesを中心に成長した素晴らしいコミュニティを見て、その一部になりたかったのです。スピードの向上とコスト削減のメリットを享受し、ベストプラクティスとツールについて業界の他の企業と連携したいとも思いました。」

- Spotify エンジニアリング、インフラおよびオペレーション担当ディレクター、Jai Chakrabarti +
+
+
+
+

「私たちのゴールは、クリエイターたちに力を与え、今・これからの消費者が真に没入できる音楽体験を実現することです。」Spotifyのエンジニアリング、インフラストラクチャおよびオペレーション担当ディレクター、Jai Chakrabartiは、このように述べています。 +2008年から始まったオーディオストリーミングプラットフォームは、アクティブユーザーが世界中で毎月2億人を超えるまでに成長しました。Chakrabartiのチームにとってのゴールは、将来のすべての消費者もサポートするべくSpotifyのインフラを強固なものにしていくことです。

-

2018年の後半に始まり、2019年に向けて大きな注力点となる本マイグレーションにおいて必要となる主要な技術の問題に対応するため、チームは2018年の大半を費やしました。「ほんの一部をKubernetesに移行したのですが、社内チームから聞こえてきたのは、手作業でのキャパシティプロビジョニングを意識する必要性が少なくなり、Spotifyとしての機能の提供に集中できる時間がより多くなってきたということです」とChakrabartiは言います。Kubernetesで現在実行されている最も大きなサービスはアグリゲーションサービスで、1秒あたり約1000万リクエストを受け取り、オートスケールによる大きな恩恵を受けている、とサイト・リライアビリティ・エンジニアのJames Wenは言います。さらに、「以前はチームが新しいサービスを作り、運用ホストを本番環境で稼働させるために1時間待たなければなりませんでしたが、Kubernetesでは秒・分のオーダーでそれを実現できます」と付け加えます。さらに、Kubernetesのビンパッキング（組み合わせ最適化）機能やマルチテナント機能により、CPU使用率が平均して2〜3倍向上しました。

+

+ マイクロサービスとDockerのアーリーアダプターであるSpotifyは、自社のVM全体にわたり実行されるマイクロサービスをコンテナ化していました。同社は「Helios」というオープンソースの自社製コンテナオーケストレーションシステムを使用し、2016年から17年にかけてオンプレミスのデータセンターからGoogle Cloudへの移行を完了しました。こういった意思決定の「我々にはさまざまなピースに取り組む、すばやく繰り返す作業を必要とする自律的なエンジニアリングチームが200以上あり、彼らを中心とした文化があります」とChakrabartiは言います。「したがって、チームがすばやく動けるようになる開発者のベロシティツールを持つことが非常に大事です。」

しかし、2017年の終わりまでには、「小さなチームがHeliosの機能に取り組むのは、それよりもはるかに大きなコミュニティで支持されているものと比べると効率的ではない」ことが明らかになった、とChakrabartiは言います。「Kubernetesを取り巻き成長した驚くべきコミュニティを見ました。その一員になりたいと思いました。スピードの向上とコストの削減による恩恵を受けたかったですし、ベストプラクティスとツールをもつ他の業界と連携したいとも思いました。」同時にこのチームは、活発なKubernetesコミュニティにその知見でコントリビュートし、影響を与えることも望みました。 -{{< case-studies/quote author="Spotify エンジニアリング、インフラおよびオペレーション担当ディレクター、Jai Chakrabarti" >}} -「Kubernetesを中心に成長した素晴らしいコミュニティを見て、その一部になりたかったのです。スピードの向上とコスト削減のメリットを享受し、ベストプラクティスとツールについて業界の他の企業と連携したいとも思いました。」 -{{< /case-studies/quote >}} -{{< case-studies/lead >}} -「私たちのゴールは、クリエイターたちに力を与え、今・これからの消費者が真に没入できる音楽体験を実現することです。」Spotifyのエンジニアリング、インフラストラクチャおよびオペレーション担当ディレクター、Jai Chakrabartiは、このように述べています。2008年から始まったオーディオストリーミングプラットフォームは、アクティブユーザーが世界中で毎月2億人を超えるまでに成長しました。Chakrabartiのチームにとってのゴールは、将来のすべての消費者もサポートするべくSpotifyのインフラを強固なものにしていくことです。 -{{< /case-studies/lead >}} +
+
+
+
+ 「このコミュニティは、あらゆる技術への取り組みをより速く、より容易にしてくれることを強力に助けてくれました。そして、私たちの取り組みのすべてを検証することも助けてくれました。」

- Spotify ソフトウェアエンジニア、インフラおよびオペレーション担当、Dave Zolotusky -

マイクロサービスとDockerのアーリーアダプターであるSpotifyは、自社のVM全体にわたり実行されるマイクロサービスをコンテナ化していました。同社は「Helios」というオープンソースの自社製コンテナオーケストレーションシステムを使用し、2016年から17年にかけてオンプレミスのデータセンターからGoogle Cloudへの移行を完了しました。こういった意思決定の「我々にはさまざまなピースに取り組む、すばやく繰り返す作業を必要とする自律的なエンジニアリングチームが200以上あり、彼らを中心とした文化があります」とChakrabartiは言います。「したがって、チームがすばやく動けるようになる開発者のベロシティツールを持つことが非常に大事です。」

+
+
+
+
+ もう1つのプラス：「KubernetesがHeliosを補完するものとして、そして今はHeliosを代替するものとして非常にフィットしたものだったので、リスク軽減のためにHeliosと同時に稼働させることができました」とChakrabartiは言います。「マイグレーションの最中はサービスが両方の環境で実行されるので、さまざまな負荷・ストレス環境下でKubernetesの有効性を確認できるようになるまではすべての卵を1つのバスケットに入れる必要がありません。」 + +

-

しかし、2017年の終わりまでには、「小さなチームがHeliosの機能に取り組むのは、それよりもはるかに大きなコミュニティで支持されているものと比べると効率的ではない」ことが明らかになった、とChakrabartiは言います。「Kubernetesを取り巻き成長した驚くべきコミュニティを見ました。その一員になりたいと思いました。スピードの向上とコストの削減による恩恵を受けたかったですし、ベストプラクティスとツールをもつ他の業界と連携したいとも思いました。」同時にこのチームは、活発なKubernetesコミュニティにその知見でコントリビュートし、影響を与えることも望みました。

+チームは、本マイグレーションにおいて必要となる主要な技術の問題に対応するため、チームは2018年の大半を費やしました。「レガシーのインフラをサポートしたり連携するKubernetes APIやKubernetesの拡張性機能を多く使うことができたので、インテグレーションはシンプルで簡単なものでした」とサイト・リライアビリティ・エンジニアのJames Wenは言います。 -{{< case-studies/quote - image="/images/case-studies/spotify/banner3.jpg" - author="Spotify ソフトウェアエンジニア、インフラおよびオペレーション担当、Dave Zolotusky" ->}} -「このコミュニティは、あらゆる技術への取り組みをより速く、より容易にしてくれることを強力に助けてくれました。そして、私たちの取り組みのすべてを検証することも助けてくれました。」 -{{< /case-studies/quote >}} +

+マイグレーションはその年の後半に始まり、2019年に加速しました。「私たちはステートレスなサービスに注力しています。最後に残る技術的課題を突破したら、それが上昇をもたらしてくれると期待しています」とChakrabartiは言います。「ステートフルサービスについては、より多くのやるべきことがあります。」 +

+今のところ、Spotifyの150を超えるサービスのごく一部がKubernetesに移行されています。 -

もう1つのプラス：「KubernetesがHeliosを補完するものとして、そして今はHeliosを代替するものとして非常にフィットしたものだったので、リスク軽減のためにHeliosと同時に稼働させることができました」とChakrabartiは言います。「マイグレーションの最中はサービスが両方の環境で実行されるので、さまざまな負荷・ストレス環境下でKubernetesの有効性を確認できるようになるまではすべての卵を1つのバスケットに入れる必要がありません。」

+「社内のチームから聞こえてきたのは、手作業でのキャパシティプロビジョニングを意識する必要性が少なくなり、Spotifyとしての機能の提供に集中できる時間がより多くなってきたということです」とChakrabartiは言います。 -

チームは、本マイグレーションにおいて必要となる主要な技術の問題に対応するため、チームは2018年の大半を費やしました。「レガシーのインフラをサポートしたり連携するKubernetes APIやKubernetesの拡張性機能を多く使うことができたので、インテグレーションはシンプルで簡単なものでした」とサイト・リライアビリティ・エンジニアのJames Wenは言います。

+Kubernetesで現在実行されている最も大きなサービスはアグリゲーションサービスで、1秒あたり約1000万リクエストを受け取り、オートスケールによる大きな恩恵を受けている、とWenは言います。さらに、「以前はチームが新しいサービスを作り、運用ホストを本番環境で稼働させるために1時間待たなければなりませんでしたが、Kubernetesでは秒・分のオーダーでそれを実現できます」と付け加えます。さらに、Kubernetesのビンパッキング（組み合わせ最適化）機能やマルチテナント機能により、CPU使用率が平均して2〜3倍向上しました。 -

マイグレーションはその年の後半に始まり、2019年に加速しました。「私たちはステートレスなサービスに注力しています。最後に残る技術的課題を突破したら、それが上昇をもたらしてくれると期待しています」とChakrabartiは言います。「ステートフルサービスについては、より多くのやるべきことがあります。」

-

今のところ、Spotifyの150を超えるサービスのごく一部がKubernetesに移行されています。「社内のチームから聞こえてきたのは、手作業でのキャパシティプロビジョニングを意識する必要性が少なくなり、Spotifyとしての機能の提供に集中できる時間がより多くなってきたということです」とChakrabartiは言います。Kubernetesで現在実行されている最も大きなサービスはアグリゲーションサービスで、1秒あたり約1000万リクエストを受け取り、オートスケールによる大きな恩恵を受けている、とWenは言います。さらに、「以前はチームが新しいサービスを作り、運用ホストを本番環境で稼働させるために1時間待たなければなりませんでしたが、Kubernetesでは秒・分のオーダーでそれを実現できます」と付け加えます。さらに、Kubernetesのビンパッキング（組み合わせ最適化）機能やマルチテナント機能により、CPU使用率が平均して2〜3倍向上しました。

+
+
+
+
+ 「レガシーのインフラをサポートしたり連携するKubernetes APIやKubernetesの拡張性機能をたくさん使うことができたので、インテグレーションはシンプルで簡単なものでした」

- Spotify、Spotifyエンジニア、James Wen +
+
-{{< case-studies/quote - image="/images/case-studies/spotify/banner4.jpg" - author="Spotify、Spotifyエンジニア、James Wen" ->}} -「レガシーのインフラをサポートしたり連携するKubernetes APIやKubernetesの拡張性機能をたくさん使うことができたので、インテグレーションはシンプルで簡単なものでした」 -{{< /case-studies/quote >}} +
+
+ Chakrabartiは、Spotifyが見ている4つのトップレベルのメトリック - リードタイム、デプロイ頻度、修復時間、そして運用負荷 - のすべてについて「Kubernetesがインパクトを与えている」と指摘します。 +

+Kubernetesが初期の頃に出てきたサクセスストーリーの1つに、SpotifyチームがKubernetesの上に構築したSlingshotというツールがあります。「プルリクエストを出すと、24時間後に自己消滅する一時的なステージング環境を生成します」とChakrabartiは言います。「これはすべてKubernetesがやってくれています。新しいテクノロジーが出てきて使えるようになったときに、自分のイメージを超えるようなソリューションをいかにしてこの環境上で作っていくか、そのやり方を示す刺激的な例だと思います。」 +

+またSpotifyはgRPCとenvoyを使い、Kubernetesと同じように、既存の自社製ソリューションを置き換え始めました。「私たちはその時の自分たちの規模を理由にした開発をしていて、実際に他のソリューションはありませんでした」とインフラおよび運用担当のソフトウェアエンジニアであるDave Zolotuskyは言います。「しかし、そういった規模感のツールですらコミュニティは私たちに追いつき、追い越して行きました。」 -

Chakrabartiは、Spotifyが見ている4つのトップレベルのメトリック - リードタイム、デプロイ頻度、修復時間、そして運用負荷 - のすべてについて「Kubernetesがインパクトを与えている」と指摘します。

-

Kubernetesが初期の頃に出てきたサクセスストーリーの1つに、SpotifyチームがKubernetesの上に構築したSlingshotというツールがあります。「プルリクエストを出すと、24時間後に自己消滅する一時的なステージング環境を生成します」とChakrabartiは言います。「これはすべてKubernetesがやってくれています。新しいテクノロジーが出てきて使えるようになったときに、自分のイメージを超えるようなソリューションをいかにしてこの環境上で作っていくか、そのやり方を示す刺激的な例だと思います。」

+
-

またSpotifyはgRPCとenvoyを使い、Kubernetesと同じように、既存の自社製ソリューションを置き換え始めました。「私たちはその時の自分たちの規模を理由にした開発をしていて、実際に他のソリューションはありませんでした」とインフラおよび運用担当のソフトウェアエンジニアであるDave Zolotuskyは言います。「しかし、そういった規模感のツールですらコミュニティは私たちに追いつき、追い越して行きました。」

+
+
+ 「私たちが取り組んでいることに関する専門知識を得るために、コンタクトしたい人と連絡を取るのは驚くほど簡単でした。そして、私たちが行っていたすべての検証で役立ちました」

- Spotify、サイト・リライアビリティ・エンジニア、James Wen
+
-{{< case-studies/quote author="Spotify、サイト・リライアビリティ・エンジニア、James Wen" >}} -「私たちが取り組んでいることに関する専門知識を得るために、コンタクトしたい人と連絡を取るのは驚くほど簡単でした。そして、私たちが行っていたすべての検証で役立ちました」 -{{< /case-studies/quote >}} -

どちらの技術も採用するには初期段階ではありますが、「gRPCはスキーマ管理、API設計、下位互換の問題など、初期の開発段階における多くの問題に対してより劇的な影響を与えると確信しています」とZolotuskyは言います。「そのため、そういった領域でgRPCに傾倒しています。」

+
+ どちらの技術も採用するには初期段階ではありますが、「gRPCはスキーマ管理、API設計、下位互換の問題など、初期の開発段階における多くの問題に対してより劇的な影響を与えると確信しています」とZolotuskyは言います。「そのため、そういった領域でgRPCに傾倒しています。」 -

チームはSpotifyのクラウドネイティブなスタックを拡大し続けており - この次にあるのはスタックトレーシングです - CNCFランドスケープを有用なガイドとして活用しています。「解決する必要があるものを見たときに、もし多数のプロジェクトがあればそれらを同じように評価しますが、そのプロジェクトがCNCFプロジェクトであることには間違いなく価値があります」とZolotuskyは言います。

+

+チームはSpotifyのクラウドネイティブなスタックを拡大し続けており - この次にあるのはスタックトレーシングです - CNCFランドスケープを有用なガイドとして活用しています。「解決する必要があるものを見たときに、もし多数のプロジェクトがあればそれらを同じように評価しますが、そのプロジェクトがCNCFプロジェクトであることには間違いなく価値があります」とZolotuskyは言います。 -

SpotifyがKubernetesでこれまでに経験してきたことはそれを裏付けています。「あらゆる技術により速くより簡単に取り組めるようになる点で、このコミュニティは極めて有益です」とZolotuskyは言います。「私たちが取り組んでいることに関する専門知識を得るために、コンタクトしたい人と連絡を取るのは驚くほど簡単でした。そして、私たちが行っていたすべての検証で役立ちました。」

+

+SpotifyがKubernetesでこれまでに経験してきたことはそれを裏付けています。「あらゆる技術により速くより簡単に取り組めるようになる点で、このコミュニティは極めて有益です」とZolotuskyは言います。「私たちが取り組んでいることに関する専門知識を得るために、コンタクトしたい人と連絡を取るのは驚くほど簡単でした。そして、私たちが行っていたすべての検証で役立ちました。」 + + +
+
+ +