濱田孝治(182)703703件のシェア(とっても話題の記事)みなさんコンテナを使うことの意味を自信もって答えられるでしょうか?ここ1年ほどコンテナ関連の仕事をメインでやっているハマコーですが、いろんなお客様からこういったお声をいただくことが多くありました。「ECSの設定とか実際めんどい。岡山城へ登壇するにあたり、そのあたりのもやもやを自分なりに昇華したのが、本日の内容です。「AWSのコンテナサービスの何を使ったら良いのかわからない」という悩みを抱えている方には、是非一度こちらの内容を見て、ヒントを掴んでいただければと想います。́J発表資料こちらから参照できます。Deck導入「迷いないコンテナ運用を目指して」みなさん、コンテナ使っていますか?本日お話することは、一言、こちら。45分という短い時間なので、コンテナやAWS関連サービスの細かい技術要素の話はしません。どちらかというと、これからコンテナを導入してみようという人であったり、コンテナの運用に苦労している方に向けたセッションとなります。それでは、「迷いないコンテナ運用を目指して」をテーマに始めていきます。本日の話の流れは以下の通りです。最初に、コンテナそのものについて振り返りましょう。コンテナ型仮想化技術を図示したものがこちら。一般的には仮想化ソフトウェアを使わずにOSのリソースを隔離するので、起動のオーバーヘッドが少ないのが従来の仮想化技術との差別化要素です。Dockerを使うには、何がなくともDockerのインストールが必要です。Docker)からインストールしてみましょう。最初に試してみて頂きたいのがこちら。Pandocというプロダクトを使ってmarkdownファイルをWord(docx)に変換します。Dockerインストールするだけでこれが動きます。sample.mdからsample.docxを作るコマンドがこちら。sample.docxPandocのインストールも何もしていないのに、いきなり文書変換できる理由がこちら。ここで、Dockerの使い方として覚えていただきたいことは、DockerはCLIっぽく使えるということです。従来の仮想化技術とは利用用途がかなりことなります。自分好みのイメージを作るには、Dockerfileを作る必要があります。Dockerfileの凄いところは「インフラのプロビジョニングからアプリケーションのインストールまで、一つのテキストファイルで記述できる」点です。従来のEC2インスタンスをたてて、動かした場合との比較した表がこちら。インフラをコードで管理するのが最近のトレンドですが、コンテナの場合は、全てDockerfileで完結します。buildを極めたい方は、ぜひこちらの資料を御覧ください。DevelopersIO「コンテナを使う意味を考える」そこにアプリケーションがあり、コンテナ化を迷った時の判断基準として必ず抑えておくべきなのは以下の3つです。私の個人的な感触ですが、このうち2つ以上YESなら、コンテナ化を検討してみましょう。対して、コンテナ運用するには非常に微妙な例として、GitLabについて紹介します。CE、インストール方法は複数あるんですが、長きに渡って運用する場合、やらないほうが良いインストール方法があります。Imageを利用したインストールって確かに簡単なんですね。それをきちんと長きに渡って運用していくとき、常にコンテナの中に状態をもつアプリケーションの運用は、はっきり言ってDockerには向いていません。普通にEC2で運用したほうが、絶対安定します。先程の判断基準は、具体的なユースケースに基づいています。これらが必要な場合は、コンテナ化することのメリットは非常に大きくなります。複数の環境でつかうか?開発〜検証〜本番で同じイメージを使う頻繁に変更するか?どんどん機能追加をしていきたい増えたり減ったりするか?負荷に応じて弾力的に数を変えたいアプリケーションをコンテナ化するときの指針はあります。定番で王道なのがこちら。(日本語訳)もうすこし、Docker向けに焦点を絞っているのがこちら。DevelopersIOこれらの情報は是非一通り目を通しておいてほしいのですが、重要なポイントを抜粋するとこうなります。アプリケーションがこれを満たしていないのであれば、Dockerfileを作り始める前にこの対応をしましょう。「AWSにおけるコンテナについて理解する」AWSにおけるコンテナサービスを区別すると、まずはこうなります。Registry)とはその他のサービスについて説明していきますが、まず最初にお知らせしておきたいのはこちら。AWSのコンテナサービス郡を最初に理解するためには、コントロールプレーンとデータプレーンについて理解する必要があります。負荷に応じたコンテナ数のオートスケールデータプレーンとは、実際にコンテナが稼働する場所コントロールプレーンからの指示にしたがって起動コンピューティングリソースを消費(従量課金対象)状態をコントロールプレーンに通知これらの関係性を図示するとこうなります。今のサービス名とラベリングするとしたらこうなりますね。今回のセッションでも、この前提でお話していきます。Service)とはAWS完全マネージドのコンテナオーケストレーションツールです。最大の特徴は、元がAWSフルマネージドなサービスのため、他のAWSサービスとの連携が簡単という点です。ECSの内部構造は決して簡単ではないです。ここでは図示して一つずつ説明していきます。タスク定義とコンテナ定義の構造がこちら。run時に設定できる内容)が含まれており、それらを統合してタスクとしてハードウェアリソースを割り当てます。1タスクに複数コンテナを割り当てる代表的な例をあげます。クラスターとサービスの関係性がこちら。クラスターが全体的なサービスを論理的に統合し、サービスには、タスク定義から具体的にサービス提供するためのインフラ周辺の情報を登録することになります。実際にこれを、先程のタスク定義例で動かしたときの動作イメージがこちら。広く使うことができるという点です。具体的には、Kubernetesのコントロールプレーン、ここをマネージドとして提供しているのがEKSです。こちらのデータプレーンは、EC2で提供され、実際の構築はCloudFormationなどを利用することになります。ここで、EKSの各特徴をECSに比べた観点で並べてみた表がこちら。spinnaker)コンテナのコントロールプレーンとしては、ECSよりもKubernetesのほうがはるかに自由度が高く高性能といえますが、マネージド未提供なものが多いです。EKSを採用するときは、この点を真っ先に知っておく必要があります。Fargateとはサーバーやクラスターを一切管理することなくコンテナを実行できます。仮想マシンのクラスターのプロビジョニングが不要ECSおよびEKSに対応したコンピューティングエンジンコンピューティングリソースに対しての料金としてはEC2より割高(1割〜2割)EC2オンデマンドに比べて、ランニング費用は割高ですが、以下のメリットを享受できます。ホストインスタンスの管理が省けることEC2の余剰リソースが不要セキュリティはAWS側で常にカバーオートスケールの設定も不要この概念を、ごっつわかりやすい図で表したのがこちら。(引用元:https://www.slideshare.net/AmazonWebServices/operational-excellence-with-containerized-workloads-using-aws-fargate-con320r1-aws-reinvent-2018/40)管理コストを氷山で表しています。水面から出ていて目に見える部分のコスト(ランニング費用)は、Fargateのほうが大きいですが、目に見えない運用上のコスト(スケーリング設定、セキュリティ管理、インスタンス管理)は、EC2のほうが圧倒的にでかい、ということです。気になるランニング費用も先日のアップデートで、大幅に下がりました。利用を検討してみてください。DevelopersIO後悔しない選択をする最後、これらのAWSサービスから最適なコンテナサービスを選択する方法をお伝えします。これを使ってください。Fargateは、EC2を隠蔽することでコンテナの管理〜運用に特化することができる素晴らしいサービスです。最初に検討すべきなのは、Fargateであると断言します。EC2と比べてFargateではできないこともあるので、注意が必要です。Logsのみに出力される(Fluentdは将来対応予定)EFSが利用できない複数タスクで同一のローカルリソースを共有することが現状無理S3などを利用できないか検討するスポットインスタンスが使えないEC2でオートスケール部分をスポットインスタンスを使うことでコスト削減するなどの方法が使えないホストインスタンスに導入する前提のセキュリティソフトが利用できないコンテナ単体でセキュリティをチェックする仕組みが必要GPUインスタンスなど、リソース最適化されたEC2インスタンスが利用できないWindowsコンテナが利用できないでは、EKSを使うパターンとしては何があるでしょう?代表的なパターンとしては、もともとk8sを自前(オンプレ、EC2)で運用していた場合。この場合は、もともとあるk8sのノウハウを活かしながら、コントロールプレーンの管理をマネージドに任せることでTCOを削減できます。ひとつ、EKSの導入に重要なポイントは?これ、案外真面目に言ってます。Kubernetesを学ぶということは、モダンな分散アプリケーションのプラットフォームを管理する方法を学ぶということです。本来的にはアプリケーションの特性に応じて最適なプラットフォームを選択するのが筋ですが、オープンなプラットフォームであり、関連するサードパーティーやOSSが非常に充実して、今一番勢いがあるのは間違いなくKubernetesです。いった技術にど真ん中から飛び込みながら、貪欲に新しいものにチャレンジしていく組織であれば、EKSも非常に良い選択肢となりうるでしょう。迷いないコンテナ運用を目指して迷いないコンテナ運用を目指してということで、45分お話させていただきました。そもそも検討しているアプリケーションがコンテナに向いているかきちんと検討するそのアプリケーションのワークロードに当てはまるAWSのコンテナサービスを選定する途中で状況が変わったら躊躇なく再検討しよう様々な場面で運用しているアプリケーションをコンテナ化したほうが良いかどうか、AWSで何を使うか、検討はされると思いますが、今日の話が皆様のよりよいコンテナ運用の一助となれば、これほど嬉しいことはありません。それでは、今日はこのへんで。濱田(@hamako9999)でした。発表スライドはこちら。