Hakusan Mafiaアドベントカレンダー１日目を余語 [Qiita|facebook|github] が担当します！
2016年頃から、SRE(Site Reliablity Engineering)や DevOpsなどを意識するような開発事例が出てきて、
サーバーサイドエンジニアもインフラを意識した開発をしてきました。
※以下に、インフラ 初心者の考察であるため、的を外している点ありましたら
突っ込みを頂けますと幸いですm(_ _)m
その中で、自分で0からサービスを作り、独自ドメインまでとってSSL対応をし、デプロイ・運用した経験から
何か新しいサービスを世に出した際に最低でも知っておくべきインフラの知識を共有します。
書いている中で、一つの記事では到底収まらないと判断したので三回に分けています。
本番環境をGCP/AWSで何個か作り、インフラについて少しわかったこと【SSL証明書編】
本番環境をGCP/AWSで何個か作り、インフラについて少しわかったこと【GCP環境構築編】（12/5 更新）
本番環境をGCP/AWSで何個か作り、インフラについて少しわかったこと【パフォーマンス改善編】
##1. Webサービスにとってのインフラとは
サーバサイドエンジニアを**「ファイルやDBへのアクセス・その他目に見えない動的な処理を記述するエンジニア」と定義すると、インフラエンジニアは「アプリケーションやミドルウェアを稼働させるためのネットワーク構成を行うエンジニア」**と思っています。
自分が学生時代、実務ベースで実際に行った業務としては
- 日常的な業務
- OS（Linux等）の導入、設定
- ミドルウェア（WEB・DBサーバ）の導入、設定
- メンテナンス（メモリ、ディスク容量の調整、ログの確認）
- パフォーマンス監視
- ユーザー権限管理
- 突発的な業務
- サーバ移行作業（旧サーバから新サーバへのデータ移行 EC2 -> ECS）
- サーバ障害時の対応
など「日常的」な業務と「突発的」な業務等に分けられるかと思います。
##2. 昔のサーバ管理から今のクラウドコンピューティングまでの変遷
端的に言うと、「昔はサーバを起動することがすごく大変だった」と言うこと。
広大な土地に、データセンターを作り、蓄電池や発電機を設置（停電のため）したり、東西に設置（建物の物理的な被害）したりしている業者から借りるのが一般的だったはずです。今は、AWS、GCPなどクラウドコンピューティングと呼ばれるサーバ提供サービスにより、簡単にインターネット経由でネットワーク管理ができるようになりました。そのため、良くも悪くもサーバー利用者は裏側についての知識があまりない状態でも簡単にデプロイできるようになりました。そこで簡単にデプロイできてしまったけれどもう少し細かくインフラを見ていかないと 「いざ、移行しよう」 といった際に思ったようにいかなくなるのではと思います。
##3. この記事を通しての課題
「http から https://にするイメージはできたんだけど、方法が何種類があって...どんなことを考慮して決める必要があるんだっけ?」
という初歩的な問いを提示しておきます。
この記事を最後まで読んで理解できれば判断材料が分かります。(AWSでのデプロイが済んだ状態で話を進めています)
##4. サーバ構成が済んだ状態
WEBエンジニアがアプリケーションをデプロイするだけの状態に一応なっていることを確認しています。
例) AWSを利用しRoRのアプリケーションサーバを構成が終わっているという段階
- 仮想マシン起動
- ネットワーク・セキュリティ設定
- パッケージインストール
- ユーザー・ディレクトリ作成、権限調節
- SSH鍵設定
- WEBサーバインストール・設定
- Rubyインストール
- 監視システム
- デプロイ
##5. デプロイ後のSSL証明書の設置
基本的に自分のポートフォリオサイトなどでない限り、httpではなくhttps通信をするのがマストです。
その際にSSL証明書というのをどこかで発行するのですが、いくつか発行方法があります。
1.web機能のあるミドルウェアであるapacheやnginxにSSL証明書を設置する方法
2.AWSのようなGUIのコンソール上でSSL証明書を設置する方法
どちらが良いかはサービスの特性で変わってきますが、
- ELBを使用しているのか？
- 今後アクセス負荷はどうなるのか？
などを判断して決めるのが良いと思います。
自分で0から作成したサービスの例だと、オンラインゲームや画像投稿サイトなどではなく、高負荷なサーバがあまり多くなく、ELBは利用しなくて良いと判断したため1の手段をとりました。
###5.1 CPU使用率
すでにサービスを運用しているのであれば、サーバ側でCPU使用率を見るためにtopコマンドを使います。
ここでのキーワードは 「CPU使用率」と「ロードアベレージ」 です
A
top - 18:46:49 up 54 days, 11 min, 1 user, load average: 0.00, 0.00, 0.00
Tasks: 78 total, 1 running, 77 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.3%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1017260k total, 804972k used, 212288k free, 50264k buffers
Swap: 0k total, 0k used, 0k free, 302120k cached
B
top - 15:17:20 up 127 days, 12:58, 1 user, load average: 0.20, 0.95, 7.95
Tasks: 94 total, 1 running, 93 sleeping, 0 stopped, 0 zombie
Cpu : 5.0%us, 1.0%sy, 0.0%ni, 84.0%id, 10.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 4049876k total, 3314092k used, 735784k free, 152792k buffers
Swap: 0k total, 0k used, 0k free, 1310228k cached
まず確認した方が良い箇所は三箇所です。
- RailsなどのプログラムのCPU使用率（%us）
- 使われていないCPU使用率（%id）
- ディスクアクセス中のCPU使用率（%wa）
ちなみにCPUはサーバのリソースをくってしまうボトルネックの4つ(他、メモリ、ディスク、ネットワーク)のうちの1つであり、プログラムの処理が行われる部分と考えてください。理想としてはディスクアクセス(%wa)を限りなく低くしつつ、CPU使用率（%us）をできる限り高い状態に維持することが費用対効果の高いサーバ運用となります。ただ、バッチ処理やデプロイのために余分なリソースを持たせる必要もあります。また、CPUのコア数が複数の際は、負担が偏ってないかなども注意する必要があります。（全体%usが60%でも1つ目のコアが100%で二つ目が20%など）
###5.2 ロードアベレージ
ロードアベレージとは「CPUに対し、どのくらいタスクが課されているか」という指標です。
個人的には、「load averageがアクセスのピーク時に10以上であれば負荷分散したほうが良い(ELBを導入した方がいい)」と思ってサービスを運用しています。
Topコマンドで見ることができるload averageは、左から「1分, 5分, 15分以内のタスク量」を表し、時間あたりの待機タスク数(1分間、5分間、15分間)を表します。
Bを例に見て見ると
**「15分前~5分前には平均的に7を超えるタスク（プロセス）があり、非常に負荷が高かった。ただ、少しずつタスクは減り、現在ではほとんどない（0.20）」**ということが読み取れます。
厳密に、ロードアベレージのタスクは CPU処理状態 + ディスクアクセス中の状態 のため、これを見ると、
「コードが悪いのか他に処理が関係しているのか」の判断基準になったりもします。
よってA、B共にELBを入れるまでもないと言えるでしょう。
2のAWS証明書サービスであるACMは無料である代わりに、EC2一台に対して証明書を設置することができないので、EC2(複数のサーバ)に対して負荷分散を行わないのであればELBが不要になります。その際、証明書機能も削除してしまうので、特にEC2を一台でのみ運用する場合であれば1で良いかと思います。
6. SSL証明書の設置時に考慮するインフラの総括
まとめると、SSL証明書の設置に関しては下記のことを知ってる必要があると言えます。
- サーバの台数?
- ELBは使用しているか?
- 証明書を設定するドメインはあるか?
- 取得した証明書ファイルはあるか?
- 完全にhttps化するか?
- 今後のアクセス負荷はどうなのか？
ということを考慮する必要があります。
「ELBが必要ない、かつ今後も負荷があまり増えそうにない予定であれば、
ACMを利用せずに、ssl証明書を外部(無料 or fujiなど)で発行して、適用させる」
ことが現時点ではいいのではないかと思います。
状況によって変わりますが、あくまで参考にしてください!!
次回もお楽しみに!!
**本番環境をGCP/AWSで何個か作り、インフラについて少しわかったこと【GCP環境構築編】**（12/5 更新）
本番環境をGCP/AWSで何個か作り、インフラについて少しわかったこと【パフォーマンス改善編】