負荷とユーザー数の点で、iFunnyが真の高負荷サービスであることを誰もが知っているわけではありません。 APIは1秒あたり約15,000のリクエストでピークに対応し、分析システムは1日あたり約50億のイベントを処理し、最大400のEC2インスタンスが全機能をサポートします。 したがって、アプリケーションには強力なエンジニアチームが必要です。 負荷の高いシステムの典型的な問題を解決し、毎日作業を改善するために、iFunnyチームは常に新しいツールとソリューションを探しています。 そして今回は、グローバルITコミュニティの主要な貢献者の1つであるKelsey Hightowerとのインタビューを無視することは不可能でした。 翻訳の価値とあなたの注意。
あなたの多くは、 サーバーレスという言葉を少なくとも一度聞いたことがあるでしょう。 アプリケーションを実行するためにサーバープールを維持する必要がないことを意味するパラダイムは、クラウドコンピューティングの世界で急速に人気を集めています。 Function as a Service（FaaS）プラットフォームを正しく使用する方法と、AWS LambdaとGoogle Cloud Functionsの登場により世界がどのように変化しているかについて、すでに議論が進行中です。
サーバーレスと同じ誇大広告の波で、 DevOpsとKubernetesという言葉が絶えず現れます。 数え切れないほどのガイドや体験談がネットワークに登場し、彼らの言及でますます多くの空席が開かれます。 しかし、この情報ノイズから正確に何がエンジニアや管理者にとって本当に役立つのでしょうか？ そして、日々の仕事で新しいテクノロジーを使用する価値をどのように判断しますか？
Cloud Guruは最近、ITの世界で非常に有名な人物であるKelsey Hightowerへのインタビューを公開しました。
Kelsey Hightowerは現在、 Google Developer Advocateであり、Kubernetesプロジェクトの主要な貢献者の1人です。 ITコミュニティでは、Kubernetesへの貢献だけでなく、米国およびヨーロッパでの会議での定期的なプレゼンテーションでも知られています。 ケルシーのパフォーマンスは通常、たくさんの面白いジョークと興味深いデモスタンドでいっぱいです。
ケルシー、あなたはKubernetesの第一人者です。 このプロジェクトに参加したきっかけは何でしたか。また、もともとKubernetesと仕事をしたきっかけは何ですか
-私は、金融、スタートアップ、ウェブホスティング、さらにはいくつかのデータセンターの分野でシステム管理者として働いていました。 インフラストラクチャの管理の難しさに精通しており、コンテナが登場するずっと前から、どこでも実行、仮想化、構成管理などの原則の人気のピークを経験しました。
開発者のところに行くと、開発エンジニアと保守エンジニアの違いを解決しようとして、ローカル環境からコードを展開することがどれほど難しいかがわかりました。
さらに数年が経ちます。 私はCoreOSで働いており、目の前でGoogleはDockerCon-2014でKubernetesを立ち上げています。 その時までに、彼らはすでにGitHubにリポジトリを持っていましたが、実際にはドキュメントがなかったため、プロジェクトを使用することは不可能でした。
私は袖をまくり、真っ直ぐにコードベースに突っ込んだ。 私はラップトップにKubernetesをインストールして学習する方法に関する「最初の」投稿を書きました。 この投稿はHackerNewsの一番上にありました-Googleのプレスリリースよりもさらに高い！ これが、CoreOSがKubernetesコミュニティでその位置を見つけた方法です。
しかし、当時、CoreOSはKubernetesにあまり関心を示さなかったため、私は自分のイニシアチブで密輸を始めました。 夜には、バグを判定し、テストをリファクタリングし、コードベースを構造化しました。 会議でKubernetesについて話す前に、その開発に多大な努力をしました。
彼は私が以前抱えていた問題を本当に解決したので、私にインスピレーションを与えました。 それは洞察のようなものでした。 10年前に存在した場合、人生は1桁良くなります。 そして、私はKubernetesが持つ可能性があるものを見ました。それは人々が将来ではなく、今ここで働くことを容易にします。
それでは、Kubernetesはどのようにして今の生活を楽にしているのでしょうか？
-その一貫性のため。 Kubernetesは、最高のシステム管理者ができることを行います。 これにより、目的の環境にコードを簡単に展開できます。
3、4年前、「パーティション」の概念がKubernetesに登場する前から、ネットワークスタックに関連するすべてが明らかにその主な利点でした。それは、コンテナの展開とその管理です。
複数のコンテナとマシンのプールがあるとします。 Kubernetesで数行の設定を行った後、「Run this container」と書くことができます。 そして、あなたはそれがどのように始まるかを見るだけです。 あるマシンのプラグを抜くと、Kubernetesはコンテナを別のマシンに移動します。 今日誰もがこれを行うことができないという単なる事実は、Kubernetesの進歩を物語っています。
そして今、これらの3、4年後、Kubernetesは本質的にコンテナの世界を吸収しました。 しかし、並行して、サーバーレステクノロジーとFaaSが登場しました。これらは、あなたが話しているインフラストラクチャ管理の問題のいくつかを解決します。 FaaSをコンセプトとしてどう思いますか？
-CGIを使用して初めてFaaSに遭遇したとき。 これは次のように機能しました。いくつかのPHPコードが作成され、Apacheの下に置かれました。 その後、ApacheはHTTP経由でリクエストを受信したときにコードを呼び出しました。 その後、いくつかの重要な制限がありました。スケーリングも、「クラウド」の概念も、これを任意の言語で実装するための理解可能なAPIもありませんでした。
今、AmazonがLambdaでこのアイデアを実現するためにもう一度試みている方法がわかります。 彼らはあなたのコードを取得してクラウドで実行するだけで、認証、データベース、APIゲートウェイなど、アプリケーションに必要な多くのコンポーネントを提供できると言います。
Lambdaは、コストモデルの点でもCGIスクリプトとは異なります。 機能請求でゲームのルールを変える何かを見ますか？
「この費用モデルは「通話料金を支払う」と理解しています。」 そして、この概念は多くのクラウドリソースに浸透します。
個人的には、FaaSはクラウドの開発環境だと考えています。 「クラウドプロバイダーとして、イベント、メッセージキュー、その他の類似のサービスを提供しています。 これらのサービスを使用するSDKの料金は請求しません。 したがって、できるだけ多くの顧客を引き付けることを目的としているため、高い参入しきい値を作成したくありません。」
Kubelessを使用してKubernetesクラスターで関数を実行することもできます。 これで、コンテナとサーバーレスの両方のコンセプトの最高の組み合わせがわかりますか？
-環境が仮想マシンのプールで構成されている場合、アプリケーションを実行する前に多くの作業を行う必要があります。 展開の前に、構成管理と多くの同様のツールが必要です。
Kubernetesは、より柔軟な抽象化を提供することでこの水準を引き上げます。コンテナを与えるだけで、起動する方法を正確に言うことができます-そして、あなたは自由です！ ただし、サーバーレスプラットフォームを提供する重要なワークフローはまだありません。 また、必要な場合は、KubelessなどをインストールしてKubernetesの上にオーバーレイできます。
これで、コードの一部を関数としてダウンロードし、すぐに実行できます。 FaaSからのすべてのオファーは、サービス用に洗練されたコンテナーを使用することを覚えておくことが重要です。 また、Kubernetesを使用すると、同じコンテナに加えて、オープンソース製品を使用できるため、プラットフォームを完全に可視化して制御できます。
FaaSは特定のタスクに対して優れた抽象化を提供しますが、すべての人に対してではありません。 Kubernetesは、多くの人にとって（特に仮想マシンの世界から来た人にとって）理解しやすく便利な最高レベルの抽象化を提供します。 サーバーレスは、その中核にある次のレベルの抽象化です。
数年にわたって開発されてきたKubernetesクラスターがある場合、AWS Lambdaが備えている機能を実装してみませんか？ Kubernetesをより高いレベルで新しいワークフローを作成するための基盤とするために必要なすべての抽象化をすでに持っています。 サーバーレスであっても。
Kubernetesはほとんどのエンジニアにとって最も便利な抽象化のままであると思いますか、それとも多くがFaaSレベルでアプリケーションを開発し、開発を開始しますか？
-人々は自分のタスクに適切な抽象化を使用する必要があります。 たとえば、Google Assistantとの統合を作成する場合、ユーザーのリクエストに応答する特定のコードを実行することだけが必要です。 そして、Google Cloud Functionsでこれを実行できます。 コンテナも、データ用のストレージも必要ありません。 これを関数として実行したいだけです。 そして、これは私の場合の最良の抽象化です。
機械学習を詳しく調べたい場合は、TensorFlowを調べてから、データセクションをマウントし、GPUにアクセスするために、コード用に別のコンテナーを分離する必要があります。サーバーレスプラットフォームは、それを実装するのに最適な場所ではなくなります。 一般的に、人々は前進し、特定の状況で機能する最高レベルの抽象化を使用する必要があると考えています。
DevOpsに関連付けられているスキルセットからさらに離れています。 前回のインタビューで、 Simon WordleyはDevOpsを一歩と呼びました。 このアイデアはあなたの経験と交差していますか？
「サイモンに同意します。」 未知の何かを研究し始めるとき、どういうわけかそれを呼ぶべきです：「私はシステム管理者です。 DevOpsを行います。 私はSREです。」 要点は、私たちの学問分野で知られているものを超えて、新しい何かを発見するとすぐに、この新しいものには独自の名前が付けられるということです。
彼らは彼らの規律に名前を付けました-私たちはテクノロジーに頼ります。 40年間DevOpsプラクティスに従事することは意味がありません。 正しい方法を理解したら、テクノロジーでアイデアを形成する必要があります。
したがって、KubernetesはDevOpsから生まれました。 その起源はGoogleに遡りますが、Kubernetesは内部使用のために行っていることの完全なコピーではありません。 Docker、Puppet、およびChefの開発者が取り組んでいるものとうまく調和しています。
Kubernetesアプリケーションを展開する場合、構成管理ははるかに簡単です。 知識と経験が含まれます。 これらはデフォルトの動作メカニズムです。 車輪を再発明する必要はもうありません。
ノードに障害が発生した場合のアクションはどうなりますか？ サービスを自動化し、リソースプールから別のマシンへのフェイルオーバーを提供する必要があります。 そして、これはすでにKubernetesで実装されています。
DevOpsの経験から、集中ログや監視などのコンポーネントが動作可能であることが示されています。 Kubernetesでは、これはすべて標準パッケージに含まれています。 DevOpsから適切なものを取得し、それを新しいテクノロジーに移行しました。 「私たち」と言うとき、私はKubernetesプロジェクトへのすべての貢献者を意味します。
現在、ほとんどのDevOpsスキルが自動化されている場合、エンジニアが習得すべき次のスキルセットは何になりますか？
-サイトの信頼性エンジニアリング。 KubernetesやLambdaのようなシステムがあるとしましょう-しかし、誰がモニターを見ていますか？ クラウドプロバイダーが私のためにすべてを行ったとしても、サービスの応答遅延が現在どのレベルであり、クライアントにどれだけ適しているかを再確認する必要があります。 プロバイダーは、クライアントとして高レベルのサービス品質を提供するよう努めていますが、これがクライアントにとって十分でない場合は問題が発生します。
なぜこれが起こるのですか？ おそらく、間違ったライブラリを使用しているか、データベースクエリを非効率的に実行しています。 そして、これはSREチームの仕事に価値がある場所です。 現在、誰が展開を心配していますか？ この問題はすでに解決されています。 しかし、展開が終わった後、クライアントが必要とするものをどのように構成するのですか？
そしてここでは、過去のルーチンから解放され、長い箱の中にあるものを先送りすることができます。 すべてのDevOpsエンジニアには、このようなボックスがあります。 「いつか集中ログを行います。 いつかCI / CDを手に入れます。」 そして今、あなたはこれらのアイデアに取り組み始めることができます。
Google Cloud Platformは、サーバーレスとKubernetesで何を最も刺激しますか？
-かなり以前からサーバーレスを行っています。 App Engineは、間違いなく前回の記事でAWSが話題にしたものです。Invent。 サーバーレスは単なるFaaSではありません。 私たちは、プラットフォームを簡単に使用する経験を人々に提供したいと考えています。 App Engineはこれをほぼ8年間続けてきたと考えています。 または、たとえば、BigQuery：完全に制御可能であり、クエリを実行するだけで、クエリの実行速度を決定できます。
コンピューティング側には、クラウド機能、FaaSサービスがあり、その対象者は絶えず拡大しており、新しいプログラミング言語やその他の機能のサポートを追加して、インフラストラクチャではなくコードに集中できるようにしています。
また、誰もが知ることのできないエンドツーエンドのソリューションもあります。 たとえば、Cloud FunctionsをDialogFlowと統合しました。 Alexaの類似物を使用したり、Google ActionsをGoogle Assistantに接続したい場合は、DialogFlowを使用できます。 スキルまたはアクションを作成すると、MLトレーニングのプロセス全体が、バックグラウンドでGCPを使用してブラウザーで確認できます。
これが、サーバーレスの核となる考え方と価値です。 計算を実行するためにインフラストラクチャをセットアップする必要はなくなりました。
このインタビューではおそらく誰かががっかりするでしょう。 「Kubernetesとサーバーレスは非常にクールですが、彼らが私の日常業務でアプリケーションを見つけるのは難しいです。 私の組織でこれらのツールの実装に遅れましたか？」そのような人々に何かアドバイスできますか？
-私はこれを言います：あなたはすでにこれらの技術を実装するために必要なスキルを持っています。 これらのスキルは、Kubernetes以前のプラットフォームの管理中に汗と血によって得られました。
あなたは自分の組織を誰よりもよく知っています。 したがって、テクノロジーの変化に関係なく、常に需要があります。 喜ぶ、それを誇りに思うようになります。誰もそのような経験を置き換えることはできません-サーバーレスでもクラウドプロバイダーでもありません。
ただし、自分の行動を検討し、その価値を理解する必要もあります。 そして、ここで、私の意見では、人々は間違いを犯します。 Kubernetesまたはサーバーレスについて聞いただけで、すぐに実装したいと考えています。 代わりに、「自分のチームまたは組織全体で何が必要ですか？」という質問を自問する必要があります。
おそらく、何かを始める前にインフラストラクチャを絶えず展開する必要があるといつも不満を抱く仲間の開発者がいるでしょう。 最初に試すように彼を招待します。 彼に自分のコードを公開して、それが最初からどのように展開するかを見てみましょう。 あなたの同僚がこれで利益を見つけたら、彼らはあなたをサポートします。 そして、あなたはそれが実際にはKubernetes、Lambdaまたは他の何かであると彼らに言います。
Kubernetesのロゴの付いたTシャツを着て、次のように言うだけでなく、ビジネスの問題にもっと精通し、なぜこのシステムが必要なのかを考えるべきです。 ！」
ゆっくり！ あなたはあなたのビジネスの問題が何であるかを正確に知っています。 最初に解決してから、Kubernetesについて話し始めます。