自分用雑記
コンテナから続き書いていきます〜
ECS、EKS、fargate
まず、コンテナって何じゃって話。
コンテナは仮想化技術の一つ。SaaSとかと何が違うのかと言うと、リソースが少なくて済む代わりにOSはその元となるOSでしか作れない。Windows上でコンテナ作ったらWindowsのみ、みたいな感じらしい。SaaSなら基盤の上にLinuxでも何でも入れれるから決定的な違い。
要するに何がしたいのかというと、仮想的な環境をいくつか作って、そこでアプリケーションを動かす、みたいな感じ。
データプレーン
実行環境のこと。Windows上でコンテナを作ったら、ってとこの、大元のWindowsのこと。この上にコンテナが乗るイメージ
コントロールプレーン
コンテナを管理する奴ら。コンテナをどのデータプレーンのosで動作させるのかとか、コンテナの死活監視とかしてくれる。オーケストレーションサービスってだけあって、指揮者的なイメージ。
レジストリ
コンテナのイメージの置き場。必要に応じてデータプレーンにコンテナを配置する。
EKS、ECSの違い
AWS純正のコンテナ管理システムがECS。
変わって、オープンソースのKubernetesのコンテナ管理システムがEKS。
どちらもEC2をデータプレーン、つまり実行環境にできる。
ECSはさらに、fargateを実行環境にできる。
fargateとは、わざわざインスタンス作らなくても実行環境提供してくれるシステム。これのおかげでインスタンスを準備、設定、調整する必要がない。
レジストリサービスはどちらもECRというサービスを使う。
使い分けとしては、サーバーの管理をなるべくしたくないならECSのfargateを。
すでに既存のシステムでKubernetesを使ってるならEKSとEC2を使う。
試験ではあまり重要視されてないけどこれから使っていきたい領域。
Lambda
ラムダって読むらしい。最初読めないの恥ずかしすぎてググった。
これも覚えて使っていきたい。個人的に名前が好き。
サーバを構築しなくてもコード実行できるサービス。
他のイベントを起因に色々行ってくれるため、S3などとの連携が容易。イベントドリブンっていうらしい。
イベントの量などに応じて自動的にサーバを大きくしたり小さくしたり、スケールしてくれる。
実際はコンテナ内で実行され、アプリが稼働しただけ課金される。何がいいかってコスト効率がいい。
普段からサーバを用意しておいてリクエスト待ちだと、使ってないときもサーバは時間単位で料金請求がくるけど、Lambdaなら使ったときだけ。だから、たまーにしか来ない処理とかに向いてる。
請求はリクエスト数と処理料で計算される。
しかし、実行の時間上限が15分なので、大量のデータ処理はできない…
対応言語は様々でrubyとかjavaとかたくさんあります（適当）
Lambda Custom Runtimesを使うことでAWSパートナーが提供する言語も使える。
AWS step functionで、いくつかのステップで構成されるアプリをLambda関数を組み合わせて構築できるらしい。何言ってるかわからない。笑笑
API Gateway
ウェブからのHTTPでのリクエストをLambdaで処理したいとき、間にこれを挟まないと行けない。
S3とかではこれを挟む必要はない。
storage Gateway
簡単に言うならオンプレのストレージとS3の仲介役。
オンプレのストレージから、S3に保存することができる。
ファイルゲートウェイ
オンプレのファイルシステムのバックエンドストレージにS3を利用
ファイルをオンプレとS3で共有するために利用
テープゲートウェイ
仮想テープライブラリ対応のバックアップソフトを使って、S3に保存
オンプレのバックアップをS3に保存するために利用
保管型ボリュームゲートウェイ
オンプレのデータのコピーをS3に保存。つまりそれをEBSに復元することも可能。
データのプライマリコピー自体はオンプレに保管されてるから保管型。
キャッシュ型ボリュームゲートウェイ
オンプレのデータのコピーをS3に保存。プライマリコピーもS3に。オンプレではよく使うデータのキャッシュのみ存在させるからキャッシュ型。
EFS
EBSの浮気野郎。異なるAZからもアクセスできるし、複数のインスタンスからアクセスできる。尻軽。
うそですべんりですごめんなさい
EBS使わずにこっち使えばよくねとか思っちゃいますね
コンピューティングとストレージは以上、次回からはセキュリティと、ネットワークへ。