LinuxのCPU使用率100%と下げ方

CPU使用率とは、プログラムがどの程度CPUを使っているかとうこと。
CPU使用率が100%でないということは、CPUに遊びがあるという状態。

CPU使用率とは: 一定の時間に対して、どれだけCPUが稼働したか。
1000ミリ秒中550ミリ秒、稼働すれば、CPU使用率は55%になる。当たり前か。

CPU使用率が高いと、アプリケーションのパフォーマンスが落ちるイメージがあるが、つまり、CPU使用率は高い方がいいのか?

CPU周波数とは
1秒間で送信できる0か1のデジタル信号の数
3.2GHzのCPUの場合、Coreで1秒間に32億回0か1の信号を送って処理ができる。つまり、クロック周波数 = 最大通信回数
3.2GHzのCoreに対して、22億4千万回の信号を送って処理すると、Core使用率は70%になる。

で、AWSのCPU周波数は?
M3.Midium Maximum Capacity:3840 MB

DBインスタンスクラスの仕様
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html
ECU: Intel XeonまたはAMD Opteronの1.0G~1.2GHz相当(クロック周波数)=最大10~12億通信回数
M3.midiumが3ECU = 3.0G~3.6GHz相当のクロック周波数 = 30~36億通信回数
M3.large(6.5ECU)に上げる?

RDS マルチ AZ 配置

Multi-AZ DB インスタンスをプロビジョニングすると、Amazon RDS はプライマリ DB インスタンスを自動的に作成するのと同時に、異なるアベイラビリティーゾーン (AZ) にあるスタンバイインスタンスにデータを複製

インフラストラクチャ障害の場合、Amazon RDS はスタンバイ (Amazon Aurora の場合はリードレプリカ) に自動的にフェイルオーバーするので、フェイルオーバーが完了するとすぐにデータベースの動作を再開できる

なるほど、そういう意味か。

同一リージョン内の独立したロケーション
障害発生時は自動でフェイルオーバーが行われ、1,2分で完了します。つまり、サービスが止まる時間はこのフェイルオーバーが行われている間だけなのでとても短い時間で済む。

RDS リードレプリカを追加する

リードレプリカの作成を押下すると、
– 送信先リージョン
– サブネットグループ
– アベイラビリティーゾーン
– 暗号化
– インスタンスの仕様

インスタンスのクラスも設定できる

レプリケーションロールがマスタとレプリカとなる。

CPU クレジット残高は、CPU 利用率がベースラインを上回り、前の 5 分間に消費したクレジットが獲得したクレジットよりも多かった場合に減少します。

AWSメンテナンス

-フェイルオーバーとは、稼働中のシステムで問題が生じてシステムやサーバーが停止してしまった際に、自動的に待機システムに切り替える仕組み

-HA機能ともいわれ、システムの可用性を高めるための冗長化.

Requiredなイベントについて、事前に知る必要がある。

RDSの詳細設計をしていこう

なるほど、ここでサブネットとavailability zoneをchoiceするのね。

メンテナンスウィンドウの設定

なるほど♪

おおおおお、すげー

やけに時間かかるじゃねーか

ステータス バックアップ中 ってどういうことだ??
とりあえずこれ、vagrantから接続できるんだろうか。。。

vagrantからはつながらないようです。
[vagrant@localhost aws]$ mysql -u root -p -h rds-mysql-server.hoge.ap-northeast-1.rds.amazonaws.com
Enter password:
ERROR 2003 (HY000): Can’t connect to MySQL server on ‘rds-mysql-server.c7fqvxerfcrm.ap-northeast-1.rds.amazonaws.com’ (110)

>EC2インスタンスのセキュリティグループには、Amazon RDS for MySQLインスタンスのセキュリティグループ[example-rds-mysql-server]に対するMySQL接続許可を追加した[example-server]セキュリティグループを割り当てます。
これか!

インバウンドルール
そのセキュリティグループに関連付けられたインスタンスにアクセスできるトラフィックを規制するルール

[ec2-user@ip-hoge ~]$ mysql -u root -p -h rds-mysql-server.hoge.ap-northeast-1.rds.amazonaws.com
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 13
Server version: 5.7.22-log Source distribution

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.

mysql>

おおおおおおおおおおおおおおおおおおお、きたきたきたーーーーーーーーーー
セキュリティグループで若干手間取りましたがwww

RDS for MySQLインスタンスに紐づけるパラメーター

サブネットグループの次はパラメーターグループをつくります。

パラメーターグループできました。

DBインスタンス

Amazon Aurora, MySQL, MariaDB, PostgreSQL, Oracle, Microsoft SQL Serverがあります。なるほど。

ユースケース 開発/テストを選択する

DBインスタンスのクラス
db.t2.micro – 1 vCPU, 1 GiB RAM
20 GiB
概算月間コスト
21.74 USD

たけーな、なんでLinuxのEC2よりDBエンジンのコストの方が高くなるのかわからん。

RDS MySQL インスタンスを立てる

まずconsoleのログイントップ

Amazon RDS for MySQLインスタンス(MySQLバージョン5.6.27のMySQLデータベースサーバ)を作成し、Amazon EC2インスタンス(Amazon Linux)からMySQLデータベースへ接続して利用開始する

RDSサービス詳細
https://aws.amazon.com/jp/rds/
対象:Amazon Aurora, PostgreSQL, MySQL, MariaDB, ORACLE, SQL Server
MongoDBなどNo SQLはないのかな。。

まず、EC2からRDS用のセキュリティグループを作ります。

サブネットグループをつくる

abilability zoneを作る

ap-northeast-1a

この ap-northeast-1a ってよく出てくるな。

——–
Amazon EC2 は、世界各地のロケーションでホスティングされています。これらのロケーションは、リージョンとアベイラビリティーゾーンから構成されています。リージョンはそれぞれ、地理的に離れた領域です。1 つのリージョンに複数のそれぞれ独立したロケーションがあり、このロケーションを「アベイラビリティーゾーン」といいます。Amazon EC2 では、お客様がインスタンスなどのリソースとデータを複数のロケーションに配置できます。複数のリージョンにまたがってリソースのレプリケーションを行うには、お客様がそのように指定する必要があります。

リージョンでロケーションが異なるのね。

なるほど、東京と大阪か。
ap-northeast-1
アジアパシフィック (東京)
ap-northeast-2
アジアパシフィック (ソウル)
ap-northeast-3
アジアパシフィック (大阪: ローカル)

サブネットが出来ました。

RDSメンテナンスウィンドウ

Amazon RDS では、Amazon RDS リソースのメンテナンスを定期的に実行する。通常、メンテナンスには DB インスタンスや DB クラスターの基盤となるオペレーティングシステム (OS) あるいはデータベースエンジンの更新が伴う。通常、オペレーティングシステムの更新はセキュリティの問題に関連しているため、できるだけ早急に適用する必要がある。

すぐに適用とすると、開始される。
CLIで調整することもできる。 AWS CLI の modify-db-instance コマンドを使用する。

aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--preferred-maintenance-window Tue:04:00-Tue:04:30
https://rds.us-west-2.amazonaws.com/
?Action=ModifyDBInstance
&DBInstanceIdentifier=mydbinstance
&PreferredMaintenanceWindow=Tue:04:00-Tue:04:30
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2014-09-01
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/rds/aws4_request
&X-Amz-Date=20140425T192732Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3

マネジメントコンソールからの設定も可能。

RDS リードレプリカ

リードレプリカというのは、読み込み専用として利用することができるマスターの複製データベース
非同期のため常にマスターと完全に内容が一致しているわけではなく常に最新のデータが取得できるということではありませんので、マスターの負荷分散用として利用するのがよい

Amazon RDS リードレプリカによって、データベース (DB) インスタンスのパフォーマンスと耐久性が向上する

1 つの DB インスタンスのキャパシティーを伸縮自在にスケールし、読み取り頻度の高いデータベースのワークロードを緩和

Amazon RDS for MySQL、MariaDB、PostgreSQL、および Amazon Aurora
読み込みクエリをアプリケーションからリードレプリカにルーティングすることにより、ソース DB インスタンスへの負荷を減らすことができる