本記事は個人の意見であり、所属する組織の見解とは関係ありません。 こちらはAWS Fargate Advent Calendar 2017の12/3分の記事です。 今日は、Ruby on Railsのアプリケーションをローカル環境で作成し、それをFargateにECSでデプロイするところをやってみます。なお、データベースとしてはAmazon RDSで作成したMySQLを利用します。 事前準備 以下のものをローカルにインストールしておきます。 AWS CLI ECS CLI Docker CLI (Compose含む) ローカル環境の構築 Docker ComposeのRailsチュートリアルが秀逸なので、これを踏襲しながら実施してみます。 docker Quickstart: Compose and Rails 手順は全てMakefileにしてみました。 new: echo "$$_gem

先日無償公開されたSoftetherをAmazon EC2のmicroインスタンスへ入れてみた。 しかしCPU性能がしょぼいのか、暗号化処理に結構負荷がかかるのか、CPUを使い果たしてしまう事態に。 さらには仮想環境ということでstealが多発し、輪をかけて使い物にならない。 ※これはEC2/microインスタンスの特性らしい。 http://qiita.com/items/8248ec4654cb809504c9 http://memo-off.blogspot.jp/2011/08/ec2-t1microcpu-steal.html そこで今回はcroup/cgroupsを用いて当該プロセスのCPU使用率を制限、さらにはstealも発生しないようにする。 ※croupは、Redhat系ならRHEL6/CentOS6から利用可能。 まずは、何もしない時のSoftetherプロセス(vpn

※2014/07/02　T2インスタンスタイプとの比較 を追記しました。 ※2014/03/13　他インスタンスタイプとの比較／m3.mediumの検証 を追記しました。 こちらの記事の二番煎じです。 cgroupで、お手軽CPU使用率制限 なるほど。 リソースにLimitかけるとstealを防げるためパフォーマンスも上がるというわけですね。 どのくらい変わるのか実験してみました。 cgroup前準備 sudo yum install libcgroup sudo chkconfig cgconfig on sudo service cgconfig start cgroup設定 上記参考URLとほぼ同じ設定です。 実行時はcpu.cfs_quota_usを変動させて比較してみました。 sudo vi /etc/cgconfig.conf # 以下を追加 group limittest {

Q: AWS Certificate Manager とは何ですか? AWS Certificate Manager (ACM) は、AWS のサービスとお客様の内部接続リソースで使用するパブリックとプライベートの Secure Sockets Layer/Transport Layer Security (SSL/TLS) 証明書のプロビジョニング、管理、デプロイを簡単にします。SSL/TLS 証明書は、ネットワーク通信を保護し、プライベートネットワークのリソースと同様にインターネットで Wウェブサイトのアイデンティティを確立するために使用されます。ACM を使用すれば、SSL/TLS 証明書の購入、アップロード、および更新という時間のかかるプロセスを手動で行う必要がなくなります。ACM を使えば、証明書のリクエストや、Elastic Load Balancers、Amazon Clou

現在開催されている、AWS Summits 2018 | San Franciscoにおいて、AWS Secrets Managerが発表されました。 AWS Secrets Manager: Store, Distribute, and Rotate Credentials Securely | AWS News Blog 2018年4月9日更新 AWS Secrets Managerを学ぶ時に便利なリソースや、概要、構造、チュートリアルなどをまとめた記事を公開しました。こちらも合わせて御覧ください。 機密情報を一元管理できる「AWS Secrets Manager」とは？概要と主要機能、動作原理、各種リソースまとめ __ （祭） ∧ ∧ Y　 ( ﾟДﾟ) Φ[_ｿ__ｙ_l〉     Secrets Managerﾀﾞﾜｯｼｮｲ |_|＿| し'´Ｊ AWS Secrets Mana

はじめに Database Migration Service（以降、DMS）とは、AWSが提供する DatabaseをMigrationするServiceです。 AWS Database Migration Service とは - AWS Database Migration Service よくある質問 - AWS Database Migration Service | AWS AWS Database Migration Serviceを使ったMySQLからRedshiftへのレプリケーション手順 まとめ ｜ Developers.IO 今回やりたかったのは、RDSにあるAuroraの特定のテーブルから、Redshiftへ継続的にマイグレーションを行い、擬似的なレプリケーションを実現させるというタスクでした。 設定 AWSのマネジメントコンソールから、Database Migra

更新版がこちらにありますので、こちらもぜひご覧ください。 これからAmazon Redshiftを始める技術者が注意すべき２２つのポイント Amazon Redshiftを使った実案件を経験してこれは注意したほうがいいなというポイントをまとめました。自分が経験した範囲で書いているので多少偏っているかもしれませんが、参考になれば幸いです。データウェアハウスって何？という方は以前入門記事を書きましたのでこちらの記事をご覧ください。 気軽に始めてみよう！クラウド時代のデータウェアハウス超入門 注意事項一覧 PostgreSQLと違う点に注意！ １件ずつINSERTするととても遅いので注意！ 主キー制約、一意制約、外部キー制約は違反してもエラーにならないので注意！ COPYコマンドは全件INSERTなので注意！ CSVでアップロードする場合の注意点！ サポートしているデータ型に注意！ エンコーディ

久々にAPI Gatewayの管理画面を開いたら、統合リクエストのページに以下のようなオプションが出ていいたので早速試して見ました。というのも、これまでAPI Gatewayを利用してLambdaを呼び出す際に、HTTPリクエストに含まれている情報を連携するために、わざわざMapping Templateを作成して、HTTPヘッダーなどをeventオブジェクトに設定していたのですが、これを使えば、HTTPヘッダーの情報がそのままLambdaに伝わるのでは！？と感じたためです。 まずはチェックをはずした状態でAPI Gatewayのテストから以下のJSONをPOSTしてみます。

API Gatewayとは Amazon API Gateway 今回新たに追加された機能 Amazon API Gateway に API 設定を簡素化する 3 つの新機能を追加（公式） Amazon API Gateway が AWS Lambda と HTTP エンドポイントで API を統合しやすくする 3 つの新機能をサポートするようになりました。従来はバックエンドのエンドポイントとの統合時に API Gateway の各メソッドと統合の動作を定義する必要がありました。今後はリクエストやレスポンスのマッピングや変換を適用せずに、すべてのトラフィックを特定のバックエンドのエンドポイントにルートすることができます。 パス変数のキャッチオールをサポートするようになりました。/store/{proxy+} といったルートを定義できます。この場合の + 記号は API Gateway に

ウィスキー、シガー、パイプをこよなく愛する大栗です。 Auroraは高速なフェイルオーバーができますがフェイルオーバー先を指定することができませんでした。本日Auroraのフェイルオーバー先の優先順序を指定できるようになりましたので、ご紹介します。 Auroraのフェイルオーバーとは？ Aurora以外の普通のRDSでは以下の図のように、障害発生時に「スタンバイ」へ切り替えるフェイルオーバーと、レプリカをマスタに変更する昇格があります。昇格の場合は明示的に操作をする必要があります。 Auroraでは以下の図のように、スタンバイへの切り替えは無く、障害発生時に「レプリカ」へ切り替えるフェイルオーバーになります。動きとしては普通のRDSのフェイルオーバーと昇格の中間の様になります。 今までAuroraではフェイルオーバー先のレプリカを指定することができませんでした。負荷が大きいレプリカへフェイ

ついにAWSのマネージドKubernetesサービス「EKS」が発表されましたね！ この記事では、これまでKubernetes on AWSに取り組んできた @mumoshu の観点でEKSについてまとめてみたいと思います。 @mumoshuって誰？ Kubernetes Incubatorのひとつ、kube-awsというKubernetesクラスタのプロビジョニングツールのメンテナです。 Kubernetes on AWSのつらみ これまでKubernetesをAWSで運用する場合の最も大きなつらみ（と思われていた）は、Kubernetesを自前でAWSにデプロイすることでした。 例えば、AzureやGCPにはそれぞれAKSやGKEといったKubernetesのマネージドサービスがあります。 AKSやGKEは「クラスタを作成する」という操作をすればKubernetesが使い始められたり、

若者言葉を無理に使って白い目で見られるDockerおじさんの西川です。 re:Inventで発表されたFargateはECSをいじる者としてはとても気になります。 aws.amazon.com ECSクラスタを構成するクラスタインスタンス（ECS用語ではコンテナインスタンス）の管理から全く開放されるのです！ マジヤバくね？（こういうところですね） ということで、AWSサポートから情報を頂きつつ、手を動かして試してみました。 前提知識：そもそもECSが何をするものなのか Dockerが何か、ECSが何かというところはこちらの記事を参考にしていただけると良いかと思います。 コンテナを使う動機 なぜDocker（コンテナ）が期待されるのか - Qiita Amazon EC2 Container Service(ECS)の概念整理 - Qiita Fargateは何をしてくれて、私は何をしなくて

EC2のサーバ監視にCloudWatchを初めて使ってみました。 カスタムメトリクスを作って、CPU使用率、HttpStatus、Memory使用率、LoadAverageの監視を行うようにしたので、手順をまとめておきます。 CloudWatchは無料枠で10メトリクス、10アラームまで設定できるとのことなので嬉しいですね。 以下、公式サイトより引用 無料利用枠* Amazon CloudWatch は無料で始めることができます。アプリケーションの多くは、これらの無料利用枠内で利用できるはずです。 Amazon EBS ボリューム、Elastic Load Balancers、Amazon RDS DB インスタンスのすべてのメトリックス同様、Amazon EC2 インスタンスの基本モニタリングのメトリックス（5分間隔）は無料でご利用いただけます。 新規および既存のお客様は、10メトリック

《課題》 VPC内でのみ名前解決をできるようにRoute 53でPrivate DNSを設定する ・Private DNSに以下の設定をする sub.example.com A xxx.xxx.xxx.xxx 《前提条件》 ・AWSの構成 VPCにEC2インスタンスが一つ 《手順》 ▼Route 53の設定 ・Hosted zonesの作成 プライベートホストゾーンを作成して対象のVPCに関連付ける 1. サイドメニュー[Hosted zones]をクリックし、[Create Hosted Zone]ボタンをクリック 2. Hosted zonesの情報を入力し、[Create]ボタンをクリック Domain Name : example.com Comment : 任意のコメント Type : Private Hosted Zone for Amazon VPC VPC ID : 対象の

target2の場合も同様に作成します。 ターゲットグループにインスタンスを登録する 作成したターゲットグループにEC2インスタンスを登録します。 ターゲットグループを選択してコンテキストメニューでインスタンスの登録と登録解除をクリックするか、ターゲットタブの編集をクリックします。 インスタンスtarget1-aとtarget1-cを登録します。 ALBにインスタンスが登録されます。ロードバランサに登録していないため状態はunusedとなります。 同様にtarget2にもインスタンスtarget2-aとtarget2-cを登録します。 ALBを作成する ALBを作成します。アプリケーションロードバランサーを選択します。 ロードバランサの基本的な設定を行います。 プロトコルはHTTPとHTTPSのみとなっています。今回はHTTPSを選択します。 HTTPSを選択したのでSSL証明書を選択しま

はじめに ELB導入時に注意すべき点があったので、紹介します。 特に注意すべき、以下の点について紹介します。 KeepAliveの設定 リダイレクトの設定 ELBを配置するVPCサブネットの大きさ ELBを配置するVPCサブネットのACL WebサーバにKeepAliveを設定する ELBからWebサーバへ接続する際に、TCP KeepAlive機能を有効にすることで、TCPコネクションを維持し、接続効率を向上させることができます。 例えば、Apacheでは以下の設定項目を修正します。 Keepaliveのタイムアウト時間は、長めに取ることで効果を得ることができます。 検索すると120秒という文献が多く出てきますが、ちょっと古い記事がほとんどです。 もしかすると、昔はタイムアウト時間が60秒に固定されていたのかもしれませんが、現在はタイムアウト時間も設定することができるため、サービスに応じ

簡単な説明 Classic Load Balancer で高レイテンシーが発生する原因は次のとおりです。 ネットワーク接続に問題がある Classic Load Balancer の設定が不適切 バックエンドインスタンスのメモリ (RAM) 使用率が高い バックエンドインスタンスの CPU 使用率が高い バックエンドインスタンスのウェブサーバー設定が不適切 外部データベースや Amazon Simple Storage Service (Amazon S3) バケットなどのバックエンドインスタンスで実行されるウェブアプリケーションの依存関係に問題がある 解決策 1.    Classic Load Balancer のネットワーク接続に関する問題のトラブルシューティングを行います。 2.    ユースケースに合わせて Classic Load Balancer を設定します。 3.    

普段 EC2 を使っていると、ロードバランサーは導入の手間的にほぼ ELB 一択になっちゃいます。 ヘルスチェックはもちろん、高負荷時には自動でスケールしてくれるし、最近やっとコンソールから使えるようになった Auto Scaling とも連携してくれるので、たいへん重宝しています。 ただ、スケールすることを前提としているため、初期状態ではそこまで性能が良くありません。 自分が試した限りでは、HTTPリクエストは 2000 req/s くらいしか捌けませんでした。 また、転送量も 800 Mbps (100 MB/sec) くらいしか稼げませんでした。 (HTTPS の使用や Keep-Alive の設定によっても変わるので一概には言えませんが、ざっくりこのくらいということで。) また、公式のドキュメントによると、スケールするのに 1 ~ 7 分はかかるらしいです。 したがって、徐々にアク

This document provides an overview of Elastic Load Balancing (ELB) on AWS. It discusses the different types of ELBs (Application Load Balancer, Network Load Balancer, Classic Load Balancer), their key features and how they can be used to build scalable and highly available systems by distributing traffic across multiple Availability Zones and targets like EC2 instances or ECS containers. It also c