タグ

ブックマーク / blog.takuros.net (6)

  • マルチAZ構成で単一AZの障害の影響を受けるのは何故か? - プログラマでありたい

    昨日の「AWSのAZの割り当ては、アカウントごとに違うという話」で宿題として残した、マルチAZ構成で単一AZの障害の影響を受けるのは何故かという問題について考えてみます。キーワードはELBです。 前提としてのELBの実装(の予想) マルチAZ構成での障害発生原因を検討する前に、まずELBの実装について考えてみましょう。5年ほど前に書いたELBの挙動からみる内部構造の推測です。 blog.takuros.net 旧ELB(CLB)をもとに書いていますが、ALBでも大きく変わらないと思います。要点としては、ELB自体は、AWSが管理するEC2インスタンス上で稼働し、バランシング先のAZにそれぞれ配置されているということです。図ではELBインスタンス(仮称)として表しています。そして、ELBインスタンスへの振り分けはDNSの名前解決で実現している点です。このアーキテクチャは私の個人的な予想ですが

    マルチAZ構成で単一AZの障害の影響を受けるのは何故か? - プログラマでありたい
  • 複数のAWSアカウント管理を制するものが、AWSを制する - プログラマでありたい

    いよいよ明日発売開始であるAmazon Web Services 業務システム設計・移行ガイドの一貫したテーマが、「企業内でどのようにAWSを使っていくのか」です。企業内でのユースケースを元に、ネットワーク/システム設計や運用管理、移行の話をしています。その中で1章を割いて説明しているのが、AWSアカウントをどのように管理するかです。 複数(マルチ)AWSアカウント管理の重要性 AWSを利用する上で、AWSアカウントをどのように管理していくかは最重要事項です。AWSアカウント管理というと、一般的には、AWSリソースの認証認可であるIAMを使った運用方法について語られることが多いです。しかし、企業内で利用する際は、それだけでは不十分です。何故なら、企業内では1つのAWSアカウントではなく、複数のAWSアカウントを作成し運用することになるからです。いわゆるマルチアカウント運用です。 企業内での

    複数のAWSアカウント管理を制するものが、AWSを制する - プログラマでありたい
  • SWF ✕ Lambda - プログラマでありたい

    AWS Advent Calendarの7日目で、全部オレの7日目です。 サーバーレス・アーキテクチャの重要な要素の1つが、Lambdaです。Lambdaは、イベント駆動でプログラムを実行するコンピュート基盤です。ユーザは、自分でサーバを管理しなくてもプログラムを実行できるため、ビジネスロジックに集中できるというメリットがあります。また、API Gatewayの登場によりHTTP Requestからの実行が容易になり、モバイルやIoTなどのバックエンジンの中核を担うようになりつつあります。 Lambdaに複雑な処理をさせたい場合 一方で、Lambdaには幾つか課題があります。複雑な処理をしたい場合、実行時間の制約や処理の責務の分割を考えると幾つかのLambdaに別ける必要が出てきます。その際は、Lambdaの多段(カスケード)実行という形になります。イメージ湧きにくいと思うので、reInv

    SWF ✕ Lambda - プログラマでありたい
    minoton
    minoton 2015/12/07
  • AWSのネットワークACLとセキュリティグループの違い - プログラマでありたい

    前回、ブラックリスト型ファイヤーウォールとしてネットワークACL(NetworkACL)を紹介しました。セキュリティグループとの役割の違いが解り難いところがあるので、改めて整理してみたいと思います。 ネットワークACL(NetworkACL)とセキュリティグループ(SecurityGroup)の違い まずセキュリティグループとネットワーク ACLの違いは何でしょうか?これは、公式のドキュメントに表形式でまとめられていて非常に解りやすいので、是非一度見て頂ければと思います。表を転載すると以下の通りです。 セキュリティグループ ネットワーク ACL インスタンスレベルで動作します(第 1 保護レイヤー) サブネットレベルで動作します(第 2 保護レイヤー) ルールの許可のみがサポートされます ルールの許可と拒否がサポートされます ステートフル: ルールに関係なく、返されたトラフィックが自動的に

    AWSのネットワークACLとセキュリティグループの違い - プログラマでありたい
  • AutoScalingのインスタンスをどう扱うのか(デプロイ編) - プログラマでありたい

    AWS Advent Calendar 2013 の 5日目 のエントリーです。ついでに独りでAdvent Calendarに挑戦中です。 みんな大好きAutoScalingの話です。AWSのAutoScalingは負荷に応じてサーバ(EC2)を自動的に縮小・拡張することが出来る夢のようなサービスです。AutoScalingを上手く活用出来れば、急なアクセス増でサーバが耐え切れずSorryページを出すという残念な結果を防げます。実際に使っていて、ピークに合わせて自動的にサーバが増えて徐々にサーバが減っていく様子をグラフで見ると、AWS使ってて良かったなぁとしみじみと実感できます。 しかし、JAWSUGなどでAWSを使い始めた人にAutoScalingを使っていると聞いても、使いたいのだけどまだ導入出来ていないという返事が多いです。何故でしょうか?幾つかパターンがありましたので、整理してみま

    AutoScalingのインスタンスをどう扱うのか(デプロイ編) - プログラマでありたい
  • 結構知らないAmazon EBSの細かい話。主にEBSのネットワークの構造について - プログラマでありたい

    先日、EBS(Elastic Block Store)のとある状況下での挙動について正確なところが知りたくて、改めて調べていました。その中で、AWSマイスターシリーズ ReloadedのEBS版を見つけたのですが、これが良い資料でした。今までEBSのネットワーク部分についてどういう構造になっているのか、正確に把握しませんでした。資料を読むことにより構造が解り、ボトルネックが発生した時にどう対処すればよいのか、より掴みやすくなりました。簡単にまとめてみたいと思います。 EBSの全体像 まずはEBSの基構造です。当たり前といえば当たり前ですが、EBSはEC2ではなくその下のレイヤーのハイパーバイザにアタッチされます。アタッチ後にOSから認識させるという形になります。また接続の方式としてはネットワーク型ですが、利用者はネットワークを全く意識せずとも使えるようになっています。(SecurityG

    結構知らないAmazon EBSの細かい話。主にEBSのネットワークの構造について - プログラマでありたい
  • 1