2016-08-12

ELBがApplication層でのロードバランシングに対応したらしい

AWS

AWSのELBが、Application層でのロードバランシングに対応したらしいです。 Application層で動くロードバランサーということで、ALBと呼ぶらしいです。

Application層で動作するロードバランサー

通信機能を7つの階層に分割するOSI参照モデル(物理層、データリンク層・・・などに分割するモデル)の最上層であるアプリケーション層で動作するロードバランサーです。

アプリケーション層で動作するため、この層で使われているHTTPというプロトコル等をもとに負荷分散をすることが可能になったようです。

現状(2016/08)のALBはHTTPリクエストのURLを用いてバランシングすることができます。

ELBでできなかったことと、ALBでできるようになること

ELBは通信を受け、処理を自身の配下のインスタンスに振り分けるという働きをしてくれていました。この際に、全ての処理を同一グループのインスタンスに負荷を分散しながら振り分けるというのがELBの挙動になります。

一方で、ALBではリクエストのURLに基づいて処理を割り振るグループを選択することができるようになります。

例えばhttp://example.com/*へのアクセスはデフォルトでGroup1に振り分けつつ、http://example.com/fugaへのアクセスのみGroup2に割り振るといったことが可能になります。

利点

これにより、より粒度の小さいサービスの組み合わせによるサービスの提供が可能になります。

例えば、ユーザーというドメインをCRUDするようなアプリケーションがあったとします。

http://example.com/user/createでユーザーを作成し、http://example.com/user/delete/{id}でユーザーを削除することができるとします。

ELBでは、ユーザーのCRUD機能を全て実装したサーバーをグループに入れておいて、http://example.com/へのリクエストを各グループに負荷分散して処理を振り分けていました。

これがALBではユーザーのCRUD機能をモノリシックに用意する必要がなくなります。

CreateやDeleteなど機能を単体で用意しておき、それらをGroup1とGroup2にそれぞれ格納します。そして、http://example.com/user/createへの通信はGroup1に処理を振り分け、http://example.com/user/delete/{id}への通信はGroup2に処理を振り分ければいいわけです。

これによって、よりマイクロなサービスの組み合わせでサービス全体を提供することが可能になるわけです。

ALBを使う上で気をつけたいこと

deployの話

アプリケーションのdeploy周りについては考える必要が出てくる気がします。

ELBを使っていた場合はユーザーのCRUD機能が一枚岩で提供されていたので、deploy時にはまるっと入れ替えることができました。

これがALBを使っている場合はCreate機能やUpdate機能が分割できてしまうので、新旧を無停止で入れ替えようとするとタイムラグが起きて問題になる気がします。

今回は例を示す際にユーザーのCRUD機能をあげましたが、分割の単位はドメインごとに切るなりなんなり、サービスにあった切り口を考える必要があるでしょう。

可用性の話

各グループにそれぞれ別の責務を負わせるわけで、それぞれのグループで可用性を確保する必要があると思われます。複数AZで各グループ用のインスタンスを起動してあげる必要があるでしょう。結構構成が煩雑になりそうなので、CloudFormationによるコード化はしておいたほうがいいかもしれません。

CloudFormationにはすでにALBも対応しているようで、AWS::ElasticLoadBalancingV2::LoadBalancerというようにElasticLoadBalancingV2ってやつを使ってあげればいいみたいです。

2016-06-10

CloudFormationでストリーム名を指定してKinesisストリームを作成することができるようになりました！

AWS

2016/06/09のアップデートでストリーム名を指定してKinesisストリームを作成することができるようになりました！

https://aws.amazon.com/about-aws/whats-new/2016/06/aws-cloudformation-adds-support-for-amazon-vpc-flow-logs-amazon-kinesis-firehose-streams-and-other-updates/

詳しい方法は下記をご参照ください。 http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-kinesis-stream.html

ここでは簡単にCloudFormationに用いるJsonをご紹介します。と言ってもかなり直感的にNameを指定してあげたらいけます。

{
  "AWSTemplateFormatVersion" : "2010-09-09",

  "Resources" : {
    "KinesisSample": {
       "Type" : "AWS::Kinesis::Stream",
       "Properties" : {
          "Name" : "Kinesisストリーム名",
          "ShardCount" : シャード数
       }
    }
  }
}

ストリーム名を指定するために、わざわざKinesisストリームを別の手段で作成していたケースにおいて、CloudFormationに集約することができるようになりました！

2016-06-05

AWS Sysops Administratorを取ってきたのでお勉強メモを晒す02

AWS 資格試験

前回から時間が空いてしまったが、メモのバージョン2をさらします。

Serverにログインできるサービス

以下の4つのみサーバーにログインできる * Elastic Beanstalk * Elastic MapReduce * OpsWork * EC2

Elastic Load Balancer Configurations

Sticky session types

2種類のスティッキーセッションタイプがある。スティッキーセッションはCookieを用いて行うが、そのCookieを誰が管理するかがこれらのオプションの違いになる。

Duration Based Session Stickiness

ELBがCookieを払い出す方式。リクエストに対してまずELBがCookieの有無を確認する。 Cookieがなければ既存のELBの振り分けアルゴリズムに従ってロードバランシングする。その後、clientにCookieを渡す。このCookieには処理を行ったインスタンスを特定する何かが含まれる。 Cookeiがあれば、そのCookieに基づいて以前処理を行ったインスタンスに処理を流す。

Cookieが有効である限りStickyセッションは継続される。 Cookieの有効期間はStickiness Policyの設定によってコントロールされる。また、処理するサーバーに問題があった場合もCookieがなかった場合と同様に処理が委譲される。

Application-Controlled Session Stickiness

アプリケーションが指定したCookieを使う。 Cookie名をELB側に教えてあげる必要がある

有効時間が来るまでは、AutoScalingしてインスタンスを増やしてもすでに確立されたセッションに従って処理を振り分けるので、有効時間が長いとなかなかスケールしない問題があるので注意。

ELBでバランシングしているASGroup内部のEC2インスタンスが、処理メトリクスを超えたのでスケーリングが走って、EC2が正しくプロビジョニングされても、新しく作成したEC2に負荷が分散されない場合はスティッキーセッションを疑いましょう。ちなみに、EC2がプロビジョニングされずに落ちている場合はEC2のコンフィグ設定が正しいか？プロビジョニングされ切る前にヘルスチェックに引っかかってないか？を疑ってみてください。

僕はEBS最適化をサポートされてEC2インスタンスにつけようとしてEC2が永遠に立ち上がらなかったことがあります。

今日はここまで

2016-05-22

AWS Sysops Administratorを取ってきたのでお勉強メモを晒す01

AWS 資格試験

先日、AWS Sysops Administratorに合格してきました。

結果は70%と結構ギリギリな感じでした。

具体的な問題については規約上発信はできないので、学習時のメモを晒します。受験直前とかに見てもらえると復習にはなるかも？

あ、ちなみに下記のcloudguruのコースを受けました。

https://acloud.guru/learn/aws-certified-sysops-administrator-associate

モニタリングに関するトピックス

AWSサービスの監視が行える。 HostLevelMetricsをデフォルトで監視可能。それ以外はカスタムメトリクスが必要になる。デフォルトで監視可能なのは以下。

CPU
Network
Disk
Status Check

メモリ使用率はカスタムメトリクスであり、デフォルトでは提供されていないので注意。

デフォルトでは5分間隔で詳細モニタリングにすると1分間隔で取得。デフォルトでは2週間データが保管される。ターミネートされたEC2のメトリクスも同様に保管される。

カスタムメトリクスは最小で1分間隔まで。

EC2 Status TroubleShootings

StatusCheck 2/2 checks passedってEC2のコンソールに出るけどそれについて。

System Status Checks

物理的なホストで問題が生じた場合、System Status Checkに失敗する。

EC2を提供する端末のハードウェアの問題とかソフトウェアの問題。

このエラーが出た場合は、EC2インスタンスを一度停止して起動し直すことで解決出来る。

インスタンスは停止して起動すると別の物理端末上でホストされることになるので、

問題が生じたホスト以外のホストで起動し直すことができるからだ。

Instance Status Checks

VM自体の問題が生じた場合、Instance Status Checksに失敗する。要するにEC2インスタンス自体のこと。

インスタンス自体で問題が起きているので、この問題が起きた場合はアプリケーションの設定を見直したり、インスタンスを再起動することで解決出来る。

EBS

General Purpose SSD

1GiB-16TiB
Maximum throughtput => 160 MiB/s
IOPS => 最大10kまででる

Provisioned IOPS SSD

4GiB-16TiB
Maximum throughtput => 320 MiB/s
IPOS => 最大20kまででる

10k以上のIPOSが欲しかったらProvisionedの方に移りましょう

ちなみにEBSボリュームを作ると初めに5.4MのIOCreditがもらえる。これは30分間3000IOPSまでバーストできる量。

暖気運転

EBSボリュームを新しく作ったりスナップショットを適用して、初めにアクセスすると初回処理が走ってIOPSの5-50%が失われる。

事前に全領域をまずは舐めるなどして暖気しておくことで性能を発揮できる。

暖機運転としては全領域に一旦データを書きに行くことが望ましい。

が、これは新規作成したボリュームなら可能だが、スナップショットから復活させたボリュームにデータを書きに行くと消えてしまうため、スナップショットから作成したボリュームでは全てのデータを読み込むことで暖機運転を行う。

今日はここまで

2016-05-02

CloudWatchにおけるEC2のStatusCheckについて

AWS CloudWatch

EC2の一覧画面に行くと、StatusCheck 2/2 checks passedとか書かれているのですが、それってなんなの？ということで調べてみた。

クリックするとSystem Status ChecksとInstance Status Checksの二つがそれぞれ成功したというふうに書かれている。

ではそれらは何なのか？そしてそれらが失敗していたらどうしたらいいのか？をいかにまとめてみた。

System Status Checks

物理的なホストで問題が生じた場合、System Status Checkに失敗する。 EC2を提供する端末のハードウェアの問題とかソフトウェアの問題。このエラーが出た場合は、EC2インスタンスを一度停止して起動し直すことで解決出来る。インスタンスは停止して起動すると別の物理端末上でホストされることになるので、問題が生じたホスト以外のホストで起動し直すことができるからだ。