スキップしてメイン コンテンツに移動

初めてのAWSメモ:VPCでELBでMultiAZのRDS

■やりたいこと

■参考にしたURL。
Amazon VPCを使ったミニマム構成のサーバ環境を構築する
Amazon RDSで仮想DBインスタンスを作成する
RDSインスタンスにMulti-AZの設定をする

■やったこと
1.Network周りの設定
(1)Amazon無料枠で申し込みする。
(2)AWS Management Consoleを起動。
(3)VPC DashboardからVPCを作る。
  -- Your VPCs
   -- Create VPC
    -- CIDR Block = 10.0.0.0/16
    -- Tenancy = Default
(4)SubnetからAZ1にPublic(10.0.1.0/25)とPrivate(10.0.1.128/25)を作る。
 またAZ2にPublic(10.0.2.0/25)とPrivate(10.0.2.128/25)を作る。
(5)Internet GatewaysからInternet Gatewayを作成する。
  -- Internet Gateways
   -- Create Internet Gateway
    -- Attach to VPC
     -- VPCをアタッチ
(6)Route Tablesを設定する。AZ1-PrivateとAZ2-PrivateはLocalのみのTableを使う。
 AZ1-PublicとAZ2-PublicはLocalとDefault Gateway(=Internet Gateway)を設定する。
  -- Route Tables
   -- Create Route Table
    -- 新しいRouteを作成し、Localと0.0.0.0/0を設定する。
  -- Subnets
   -- Public
    -- 新規に作成した0.0.0.0/0のRouteを持つRoute TableにReplaceする。
   -- Private
    -- 0.0.0.0/0のRouteを持たないRoute TableにReplaceする。

2.RDS(DBサーバ)の設定
(1)RDS Dashboardの
  -- Subnet Groups
   -- Create DB Subnet Group
    -- AZ1-PrivateとAZ2-PrivateをGroupingする。
(2)RDSを構築する。
  -- Instances
   -- Launch DB Instance
    -- MySQLを選択
     -- Do you production...でNoを選択する
     -- Multi-AZ Deployment=Yesで作成する
     -- Additional ConfigでVPCとDB Subnet Groupを選択する
     -- Management OptionsはDefaultで。
(3)Security Groupを設定する。
  -- 対象RDSのSecurity Group設定箇所をクリックする。
   -- Security Groups画面が開くのでCreate Security Group
    -- [db-servers]という名前で、Port=MySQL、Source=10.0.0.0/16のルールを作成
  -- RDS画面に戻り、対象RDSを選択してModifyをクリックする。
   -- Security Groupをdb-serversに変更する。
(4)MultiAZの動作確認
  Instances画面から対象Instanceをクリックして、Availability Zoneを確認する。
  Instance ActionからRebootする。「Reboot With Failover?」をチェックする。
  Statusがrebootingからavailableになったことを確認して、Availabillity Zoneが切り替わったことを確認する。

3.EC2(Webサーバ)
(1)EC2を構築する。Web1とWeb2の2台構築する。
  -- EC2 Dashboard
   -- Instances
    -- Classic Wizzard
     -- Amazon Linux AMIを指定
      -- AZ1-Public or AZ2-Publicを指定
      -- あとはDefaultで
      -- Security Gruop では22と80をFrom anyであける(後で80はSLBからのみに絞れると思う)
(2)EC2にElastic IPを付与する
  -- Elastic IPs
   -- Associate Address
    -- Web1、Web2両方ともに設定する。
     →たぶんGIP1つでもNATすることで外部通信可能だと思うんだけど調査していない。
(3)EC2にSSHアクセス。ユーザーはec2-user。
(4)Web1からDBSにmysqlコマンドでアクセスしてみる。
   sudo yum -y install mysql
   mysql -h dbs.xxxxxxx.xxxxxxx.rds.amazonaws.com -u user -p
(5)httpdをインストールする。Web1、Web2両方で。
  $ sudo yum -y install httpd
  $ sudo chkconfig httpd on
  $ sudo service httpd start
(6)Elastic IPに外部からWebで接続して、接続できることを確認。
(7)後で作るELBのために、簡単なindex.htmlを作っておく
  $ vi /var/www/html/index.html
   -- Web1とWeb2でどちらにアクセスしているかわかりやすい内容にしておく。

4.ELBの構築
(1)EC2 DashboardのLoad BalancersからELBを作る
  -- VPCを指定、Portは80のみ、Internalではないのでチェック無し
  -- Health checkはデフォルトのまま。
  -- Add EC2 InstancesではAZ1-PublicとAZ2-Publicを選択
   -- Create a new Security GruopでELB用のSecurity Groupを作成する。Port 80 from anyのみ。
    -- Manually Add Instances... でWeb1とWeb2をSelectする。
  -- Createしたら、2つのECがIn Servicesになっていることを確認する。
(2)ブラウザからELBのHostnameにアクセスして、Web1とWeb2のHTTPDをそれぞれ落として、
 振り分けされることを確認する。

■感想
・立ち上げるだけならとにかく楽。難しい設定を考えなくても動く。
・MultiAZのあたりは同期のタイミングとかcommitとかLockのタイミングとかその辺調べるともっと面白そう。
・ELBも振り分けまでしかしてないけど、セッションの振り分けとか管理のあたりをもっと知りたい。
・Security Groupの設定は、物理みたいに経路とフィルタのセットで考えるんじゃなくて、1つの大きなFirewallで制御しているような感じ?この辺の感覚に慣れるのが難しそう。もっと細かく制御できそうな気がするんだけどな。
・とにかく最近新しいことにチャレンジする機会が全く無くて悶々と死んだように生きていたけど、こういうことやるのめちゃくちゃ楽しい。幸せ。
・まだ届いてないけどこの本買いました。

Amazon Web Services クラウドデザインパターン実装ガイドAmazon Web Services クラウドデザインパターン実装ガイド
大澤 文孝,玉川 憲,片山 暁雄,鈴木 宏康

日経BP社
売り上げランキング : 17216

Amazonで詳しく見る by AZlink

コメント

このブログの人気の投稿

リモートワークは仕組みじゃなくて文化です

ここ最近、コロナウイルス関連の報道が数多くあるが、その中でも多くの企業がリモートワークを推奨するという記事やプレスリリースが注目を浴びている。それ自体はもちろん大変望ましい。不要な対面での接点を減らすことで感染リスクを抑えることが出来るし、通勤ラッシュや首都圏への経済集中も抑制出来るからだ。 だがちょっと待ってほしい。リモートワークというのは社員が在宅で働くことだけを指すのではない。 社員が在宅で働いても出社時と同じパフォーマンスが出ること をリモートワークというのだ。だからこの記事のタイトルで「リモートワークは仕組みじゃなくて文化です」と書いた。 弊社がリモートワークを導入したのは2011年の東日本大震災がきっかけだけれど、9年経った今、どのようにリモートワークを運用して、そしてパフォーマンスを維持しているかを共有したいと思う。以下のことが文化として根付けば、その会社のメンバーはリモートワークでもオフィスでも同じようなパフォーマンスが発揮出来るはずだ。 1.勤怠を厳密に管理しない え、だってダルくないすか。管理するの。何時に働き始めて何時に働き終わったかなんて関係ないっしょ。大事なのは働いた結果のアウトプットであり、働いた時間なんか問題じゃない。 2.休憩も厳密に管理しない え、だってダルくないすか。管理するの。何時に休憩し始め(ry 3.工数を厳密に管理しない え、だ(ry 4.目に見えるアウトプットを意識する 当然のことながら、仕事は結果が全てであり、結果が出なければどこで何時間働いたって意味がない。そして結果というのは目に見えなければ意味がない。 だからこそ、アウトプットを出すこと、アウトプットを評価することに徹底的にこだわる。それはドキュメントかもしれないし、お客様やパートナーとコミュニケーションするためのメールかもしれないし、社内の改善活動かもしれないし、メンバーへのフォローかもしれないし、ブログかもしれないし、Slackでの発言かもしれない。 とにかく目に見えないものは周りも認められない。目に見えるアウトプットしか評価されないし、そのために徹底的にアウトプットするんだ、という意識を社内でしっかりと作ることが重要。 5.コミュニケーションコストを意識する どんなに頑張っても、オンラインのコミ

これで完璧!本当に役立つテレワークマナー

コロナ禍によってテレワークを導入する企業が増えた昨今、皆様いかがお過ごしでしょうか。僕は4連休明けでダルかったので有給を取得し妻とデートしてきました。イェーイ。 さて、 弊社 も今年2月以降は全社員完全テレワークに移行しました。弊社は2011年からテレワークを導入し各自が自由に活用していたため、特に大きな問題も無くテレワーク体制に移行したのですが、全社員完全テレワークは初めての状況であり、幾つかの課題が発生しました。特に、その状況下でも新しく入社する社員がいますので、これまで社内で培ってきた暗黙の了解が共有出来ないことは大きな課題でした。 ということで、本記事では、弊社のテレワークマナーについてご紹介したいと思います。皆さんのご参考になれば幸いです。 業務の開始と終了はチャットで宣言する これはオフィス出社時でもテレワークでも変わらないのですが、業務開始時と業務終了時にはSlackで宣言しています。弊社ではこれを開店/閉店と呼んでいます。 気をつけて頂きたいのは、これは 報告ではなく共有である ということです。業務開始と業務終了を共有しておくことで、同僚が相談したり依頼をしたりできる時間を把握出来ます。この共有をしておかないと、業務開始前や業務終了後にMentionがバンバン飛んで来るかもしれません。もちろん飛んできたからって怒るメンバーはいないのですが、お互いちょっとした気遣いが出来るように、自分が働いている時間は共有しておくと良いでしょう。 これは休憩時間も同様です。昼休みにのんびりゲームしているときにスマホがブーブー鳴っていたら気が散るかもしれません。休憩開始と終了をSlackで宣言することでゆっくり休憩することが出来ます。休憩中は Display name の後ろに「休憩中」等と付けておくのも良いでしょう。 マイクとスピーカーはPC内蔵のものを使わない PCの性能は以前と比べて格段に上がっていますが、残念ながらマイクとスピーカーはそうではありません。マイクについては音質は向上しているものの、指向性が無いために周囲の音を拾ってしまいます。そしてPC操作時には、どうしても打鍵音がダイレクトに響いてしまいます。またスピーカーは、まぁ正直全く駄目です。音楽を聞くのにさえ向いていないのに、音声のやり取りなんか出来るわけがない。 マイクとスピーカーは必ず別に用意しましょ

ネガティブなフィードバックをする時に意識したい7つのこと

僕は現在は取締役兼事業本部長という立ち位置でお仕事させて頂いてますが、元々はエンジニアで、かつピープルマネージメントを15年以上しておりました。僕がマネジメントしたメンバーは合算すると200人以上になります。正直に言えば、楽しいことはたくさんあったけれど、もちろん辛いことも多々経験していまして、特にメンバーに対してネガティブなフィードバックをすることは大きな苦しみの一つです。 最近、自分の部署の若いマネージャーから、ネガティブなフィードバックを上手に行うことが難しく課題に感じている、という声があったので、僕の経験をまとめてみました。 ポジティブなフィードバックをセットにして伝える どんな人にとっても、悪い話を聞くことは楽しい経験ではありません。悪い話だけを聞き続けると、不愉快な感情が理性を覆い隠してしまいます。しかしフィードバックとは叱ることではなく、どのように改善していくかを議論するためのきっかけであり、感情的になることはマイナスに働きます。ネガティブなフィードバックを伝える時は、ポジティブなフィードバックをセットに、出来れば先に伝えます。良い点がない人はいません(そんな人は採用していないはずです)から、必ず褒めるポイント、褒めるべきアウトプットがあるはずです。ポジティブなフィードバックをセットすることで、相手の感情のバランスを取ることが出来ます。 ネガティブな内容を責めるのではなく事実として伝える 上述の通り、フィードバックの目的は叱責ではなく改善なので、「なんで出来ないんだ」とか「どうして出来なかったんだ」ではなく、事実としてのネガティブな現状を正確に伝えることが重要です。例えそれが叱責に値する内容であったとしても、どちらか一方が感情的になると必ずもう片方も感情的になるので、冷静に正しく事実のみを伝えます。 期待値を提示する ネガティブなフィードバックには、必ずあるべき姿、こちらが期待していた姿があるはずなので、それを伝えます。その際には一方的に伝えるのではなく、こちらの期待値を根拠と併せて伝え、その上で一緒にその期待値の妥当性を議論します。この期待値のすり合わせをしないと、メンバー本人の振り返りも生まれず、改善のためのアクションも「言われたからやる」だけになってしまいます。 なぜネガティブな結果になったのかをヒアリングする 人それぞれ様々な事情や環境がある