Page List

Search on the blog

2021年5月9日日曜日

ecsとasgを使ってオートスケールするサービスをterraformで構築する

 GWの自己研鑽最終日です。前回試したCapacity Providerを用いたコンテナインスタンスのAutoScaleとECSサービスのAutoScaleをterraformでやってみました。
  • すでにterraformを書いている人たちがいたので、まずはそれをリファレンスと照らし合わせながら読んで理解するところから始めた
  • terraformを書いた
    • ググると二種類のAutoScaleのどちらかをterraform化したものは出てくるのだが、どちらもやっているのは見当たらなかったので書いてみた
    • terraformのファイルのprefixに番号をつけておくと、何から作っていったのかがわかりやすくていいかもと思った
    • vpcまわりをterraformで書くのは初めてだった
    • assume roleは雰囲気しか理解してなかったが、何をするものなのかが分かった
  • 負荷をかけたり、かけなかったりして、スケールイン・スケールアウトされる様子を確認した
    • サービスのオートスケールに連動して、タスクが利用するコンテナインスタンスもオートスケールするのは地味に感動した

2021年5月7日金曜日

ecsとasgを使ってオートスケールするサービスを立ち上げる

  GWの自己研鑽4日目のメモです。

AWS ECS(EC2起動)でのAuto Scalingまわりの調査&検証をしました。

  • サービスの Auto Scaling
    • 公式ドキュメントを読んだ
      • ECSはサービスのリソース使用率(CPUやメモリの使用量)メトリクスをcloudwatchに発行している
      • このメトリクスを利用して自動的にサービスのスケールイン・スケールアウトをすることができる
    • ターゲット追跡スケーリングをやってみた
  • コンテナインスタンスの auto scaling
    • EC2起動の場合はサービスをホストしているコンテナインスタンスのauto scalingも考慮する必要がある。
    • 公式ドキュメントを読んだ
      • Capacity Providerというものを使うといいらしい
    • Capacity Provider = クラスタ中のタスクが利用するインフラを管理するやつ
      • target capacity(0~100)を定義するとその値をターゲット追跡してくれるらしい
      • 例えば100と設定するとクラスタ内にあるコンテナインスタンスのサービス使用率が100に近くなるようにscale-out/scale-inが行われる
    • Capacity Provider Strategy = どのCapacity Providerを使ってタスクのインフラを管理するかを決める戦略
      • クラスタは複数のCapacity Providerを持つことができるので、サービスを作るときにどの戦略でいくか選ぶ
      • 最低でもX個のタスクはCapacity Provider Aを使う(base値)、全体のうちY%のタスクはCapacity Provider Bを使う(weight値)というような戦略を作ることができる
    • Default Capacity Provider Strategy = デフォルトのCapacity Provider Strategy
      • サービス起動時にCapacity Provider Strategyを指定しなかった場合に使われる戦略。
      • クラスタごとに決めることができる
    • Classmethodの記事を参考に実際に動かしてみた


2021年5月5日水曜日

ビルドしたamiを使ってecsクラスタを起動する(EC2起動)

 AWSのお勉強の続きです。

前回ECS Optimized AMIをベースに作ったカスタムAMIをクラスタとして起動して、ECSを動かしました。

  • EC2起動のECSのgetting-startedをやってみる
  • ECSコンテナインスタンス = ECSコンテナエージェントを実行していて、ECSクラスタに登録されているインスタンスのこと
  • ECSコンテナインスタンスには Amazon ECS コンテナインスタンス IAM ロールが必要
  • まず空のECSクラスタを作成する
    • クラスタテンプレート「EC2 Linux + ネットワーキング」から作成しようとすると、最新のECS Optimized AMI以外は利用できないっぽい
  • 次にECSコンテナインスタンスを起動する
  • 起動したECSコンテナインスタンスをクラスタに登録する
  • バインドマウントでEC2インスタンスのライフサイクルに関連づけたデータをマウントする
  • fargate実行の場合はawslogsドライバーでcloudwatchにログストリームを送っていたが、ec2実行の場合はサーバにログインしてdocker logsすればログが見れる
  • シンプルにシステム運用する場合はfargate実行、社内に標準環境や共通のミドルウェア基盤などがある場合はAMIを作ってec2実行、という使い分けになりそう

2021年5月3日月曜日

packer&ansibleを使ってamiをビルドする

 GWの自己研鑽の続きです。

職場ではAMIの作成まわりは別のチームの人が担当しているので、自分でpackerを使うのは初めてでした。初歩的なことをやってみただけですが、雰囲気だけでも掴めて良かったです。

  • 公式サイトの aws-get-started をやってみた
    • 新しいバージョンではHCLが使えるらしい
    • 作成したリソースを削除し忘れないように注意!
      • サービス - EC2 - AMI から登録解除
      • サービス - EC2 - スナップショットから関連するスナップショットを削除
  • HCLを書くための環境を整える
    • IntelliJ に HCL プラグインを入れる
  • ECSをEC2起動するために使うカスタムAMIを作成する
    • Amazon Linux2 の ECS Optimized AMI をベースに作ることにした
      • 対象のAMI名は以下のコマンドで探せるっぽい
      • aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/recommended --region ap-northeast-1
    • ansible provisioner の設定を追加する
      • ansible-local を使うとリモートホスト上で直接 ansible を実行できる
      • ansible-local を使うためにはリモートホスト上に ansible をインストールしておく必要がある
      • とりあえず ECS から mount するようのログディレクトリを追加してみた
  • 今日の進捗

2021年4月29日木曜日

ecsで簡単なサービスを立ち上げる(Fargate起動)

GWの自己研鑽の作業メモです。

  • 公式サイトのgetting-startedをやってみた
    • Fargateを使うとサーバーの管理が不要なので便利!
  • 適当なアプリを作ってecrにpushした
    • getting-started では Docker Hub にある既存の image を使っている
    • 自作の image を使ってみたかったので、テキトーな image を作った
    • docker や ecr まわりの丁寧な説明が公式ドキュメントにある
  • ecrにpushしたimageを使ってサービスを実行した
    • クラスタ、タスク定義、サービスを作った
  • タスクとサービスの違いが曖昧だったが違いが分かった
    • タスク = どの image でどのプログラムを実行するかを定義
    • サービス = どのタスクをどのクラスタで動かすか、デプロイ戦略はどうするか、タスクを何個動かすか、負荷分散はどのようにするかを定義

今年のGWはちゃんと勉強するよ〜

  今年はコロナで海外にも行けないし、帰省もできないので、インフラまわりの勉強をします。aws ecsの知見をえるために、以下の5ステップを少しずつやっていきます。

  1. ecsで簡単なサービスを立ち上げる(Fargate起動) 
  2. packer&ansibleを使ってamiをビルドする 
  3. ビルドしたamiを使ってecsクラスタを起動する(EC2起動) 
  4. ecsとasgを使ってオートスケールするサービスを立ち上げる 
  5. ecsとasgを使ってオートスケールするサービスをterraformで構築する

2021年2月6日土曜日

ドルで言われてもすぐに分からない

ドルで言われても、それがどれくらいなのかすぐに分からない。

例えば1ドルだったら100円かと分かるのだが、「この市場は one hundred billion の規模です」と言われると「billion が 10億だから、10億が100個で1000億ドルか。これを円に直すと10兆円か」とどれくらいの数字か理解するのに時間がかかってしまう。

英語 -> 日本語の変換をした後、ドル -> 円の変換をするのは非効率なので、感覚的にオーダーを掴んでおくと良さそうな気がする。

ドル 感覚的なオーダー
1 ジュース
10 ランチ
100 財布、コート
1 thousand ギター、ブランド品
10 thousand 車
100 thousand 年収
1 million 高級マンション
10 million 宝くじ
100 million スポーツ選手長者番付
1 billion ユニコーン企業
10 billion 日本の大企業
100 billion 多国籍大企業
1 trillion 日本の国家予算