ITI Meatup #1 インフラ(SRE)チームになってから半年!! ITIインフラ技術について飲みながらお話します！(AWS/Zabbix/H2O/Ansible/Terraform/Vuls)

新卒がZABBIX3でサーバー監視を冗長化!?H2Oにも移行した！ | 宮澤 輝 様

 

 

https://speakerdeck.com/miyazawaiti/xin-zu-gazabbix3desabajian-shi-worong-chang-hua-h2onimoyi-xing-sita

 

1人目の登壇者は宮澤様。

今回はZabbix3.0を用いたサーバー監視の冗長化についてお話ししていただきました。

 

宮澤 輝 様

1995年2月14日（バレンタイン）生まれ。22歳
東京電機大学在学中に ITI インターン としてアルバイト を始め、2017年4月に新卒として入社。
インターン中に「 IT プロジェクト名鑑」のインフラ構築を担当。
社内では「 Zabbix マスター」と言われるほど監視に強く、日々あだちん氏の元でしごかれている。
趣味のロックバンドではドラムを担当。

ZABBIXで監視を冗長化した経緯

 

当時、ITI様の監視サーバーはzabbix2.2を用いて自社で構築、運用していたそうなのですが、6月にさくらがメンテナンスを発表し、メンテナンス中は監視を継続できない状態に。

これを機に、監視を2台体制で冗長化することにしたそうです。冗長化後は2つの監視サーバーを別々のサービスで構築することで、片方がメンテナンスやアップデートで動けなくなったときにも、もう片方で障害を検知できる仕組みになっています。

ZABBIX3.0

 

Zabbixとは、完全無料のオープンソースを監視するソフトウェアとのことです。

基本的にはLAMP環境にZabbixサーバーをインストールするだけで簡単にできるそうです。

Zabbixにはエージェントを介して監視データの値をとってくる仕組みがあります。そのため、監視対象のサーバーには、Zabbixエージェントというものをインストールする必要があります。ITI様では監視対象のサーバーが200台以上あるそうですが、こちらはAnsibleという構成管理ツールを用いてZabbixエージェントを自動でインストールしているそうです。

 

Zabbixではサーバーの監視の要件を整理して、グラフを並べて一気にみることができたり、必要な情報だけ通知して障害対応したりと自由に設定できることが魅力だそうです。

ITI様では稼働しているサービスのほとんどでAWSを使っているそうなのですが、AWSの障害が起きた時の対策として、Zabbixを構築するにあたってはGMOのConohaというクラウドサービスを使用しているそうです。このConohaはZabbixのスペック要件を満たしつつ2GB、3コアで月額1750円とコストパフォーマンスが非常に高いです。

スクリーン機能

 

Zabbixの構築の次はスクリーン機能についてのお話していただきました。

Zabbixの設定ではimport/exportができるそうです。

この機能を応用することで、監査対象ホストが200以上あるITI様でも効率よく設定することができたそうです。しかし、120個のグラフがリアルタイムで更新されることになり、グラフの表示がとても重くなってしまったそうです。その問題を解決するために、H2OというWEBサーバーを採用したそうです。

H2OとHTTP/2

 

H2OはHTTP/2に対応していて、速度が圧倒的に速いそうです。従来のHTTP/1.1では、HTTPパイプラインで前回のリクエストの完了を待たずに次のリクエストを送ることはできましたが、サーバーはリクエストの順番通りにレスポンスを返さなければいけなかったため、順番待ちが発生していたそうです。

その点、HTTP/2では同時に100以上のリクエストを発行可能、タイミングやレスポンスの順番が関係ない複数並列処理が可能なため、順番待ちがなく、ヘッダ圧縮によって小さなリクエストを何回送っても遅くならない点など、さまざまな利点があります。

優先度制御

 

HTTP2はただ適用するだけではなく、サーバー側の設定をしっかりしないと、せっかくの利点を生かすことができません。

H2Oには、「http2-reprioritize-blocking-assets」というレスポンスの優先度を制御できるオプションがあるそうです。

ほとんどのブラウザが、優先度の設定が対応出来ていないため、サーバ側でちゃんと設定する必要があります。  

このオプションが適用されていると、CSSとJSをまず最優先でレスポンスを返すようになっており、その次に、HTMLを返します。

この2つめの時点で、WEBページのレンダリングは開始されるので、ページのファーストビューまでの時間が早くなります。

最後に、順番を気にせず並列処理で、画像ファイルを返すことで、高速にWEBページの表示ができるそうです。

サーバプッシュ

 

H2Oにはサーバープッシュというオプションがついています。

通常、リクエストを受けてからレスポンスまでの時間をどんなに短縮したとしても、必要なファイルの数に応じて時間がかかってしまうものですが、

こちらのオプションでは、例えばHTMLファイルのリクエストを受けた時に、CSSもまとめて1回で送り、リクエストとレスポンスの回数を減らすことで、高速化を実現しているそうです。

さらに、キャッシュの有無を確認する機能がH2Oにはついているので、無駄に送りすぎることはないのでいいところづくしですね。

まとめ

▶監視は自社で構築
　→コスト大幅ダウン→しかし運用が大変

▶監視はAWS以外で冗長化するのがおすすめ
　→AWS側のネットワーク障害が起きても困ることはない

▶これからのWEBサーバはH2Oに変わっていきそう

▶Prometheusに挑戦したい

 

 

 

【AWS構成管理】TerraformでできることをAnsible AWSモジュールでどこまでできるか | 稻葉 涼 様

 

https://speakerdeck.com/vtryo/hikarabo-awsgou-cheng-guan-li-terraformdeshi-zhuang-dekirukotowoansible-awsmoziyurudedokomadedekiruka

2人目の登壇者は稻葉様。

今回はTerraformでできることをAnsible AWSモジュールでどこまでできるか検証した結果をご紹介していただきました。

 

稻葉 涼 様

1993年2月16日生まれ。
プレゼントはバレンタインと一緒にされがち。
私大心理学科卒業後、SI業界でインフラエンジニアとなる。
主に仮想基盤のストレージ構築などを担当し、
Webインフラ（自動化）をやりたいため2017年2月に第二新卒として入社。
師匠であるあだちん氏の影響によりAnsibleにハマり、
Wordpress構築依頼が多すぎなため完全自動化を作り上げた強者。
ついでに自分のブログも構築して趣味や技術情報を発信中。
(https://blog.vtryo.me)

なぜコード化を採用したのか

人によってインフラが構築時の手順が異なり、構築した人以外がインフラの動作を理解できていないことが当時社内で課題だったそうです。インフラ構築が増え、工数が膨れ上がってしまったので、コード化によって構成を分かりやすくし、個人に偏りをなくすことで工数を削減するためにコード化に踏み切ったそうです。

TerraformとAnsibleを採用した理由

TerraformとAnsibleを使っている理由については次のようにお話してくださいました。まずTerraformはサポートしているサービスが多い。それから開発スピードも早くて素直にやってて楽しい。エンジニアにとってすごい大事なので採用しています。また、Terraformでは今後リソースが増えて対応していくことができる魅力もあります。Ansibleはエージェントレスで導入コストが低く、そしてコードを書いたことない新人でも書くことができることが魅力的なので採用しています。

今回やってみたこと

今回、稻葉様にはTerraformで実装できることをそもそも得意分野の違うAnsible AWSモジュールで、どこまで再現することができるか検証した結果についてお話して頂きました。この検証は2つのポイントで見ていったそうです。

 

・Terraformでの実装と同程度の再現は可能か

・TerraformとAnsibleの使い勝手のよさがどちらか

 

■実行環境

 

VPC,securitygroup,EC2構築をAnsibleでやってみる

 

概要

Trraformを使って以下を構築

・EC2

・VPC,Subnet,Route table,InternetGateway

・SecurityGroup

 

Ansibleでの検証ポイント

・ID取得系のモジュールを使用すること

・処理結果を変数化すること

・debugモジュールで格納した値を可視化させること

・冪等性はcount_tagとexact_countでカバー

 

 

検証結果考察

・Ansibleでは作成したリソースのIDをを取得するのにモジュールを使う必要があるため、ひと手間増える

・debugモジュールを使えばJSONのプロパティが書きやすい

・上記2つを毎回やるのでplaybookが長い

 

インスタンスタイプ変更

 

概要

v0.8.8からインスタンスタイプを変更しても既存インスタンスが削除されなくなった現在Terraform0.10くらいですが、0.8以前では、インスタンスタイプをt2.microからt2.mediumにしようとするとインスタンスが削除されてしまっていたそうです。v0.8.8からインスタンスタイプが削除されなくなったので今回稻葉様はt2.microからt2.smallに変更して検証してみたそうです。playbookは先程のEC2起動と同じものを使用したため、インスタンスタイプをt2.smallに変更するだけでよいと思ったのですが、冪等性を保つためにcount_tagとexact_tagをつけていたので、何度打ってもOKになってしまい、インスタンスタイプが変わらない。そこで、一旦コメントアウトしたら新しいインスタンスができてしまい課金されてしまったとのこと。

 

 

検証結果考察

・新しいインスタンスできてしまって課金された

・TerraformはSTOPとSTARTで楽にインスタンスタイプが変更できる

EBS容量を増やす

 

EBSを例えば8GiBから30GiBに変更するとインスタンスが消えて再作成される。Terraformの処理をみると一度インスタンスが消えて再び立ち上がっている。Ansibleでは同じく消えるのか検証した結果をお話してくださいました。先程と同じ質のplaybookでボリュームサイズを30GiBに変えて1回たたきます。やはり新しいインスタンスができてしまいました。ただ、インスタンスは消えたりはしないので、安全ではあるそうです。

 

 

検証結果

やはりインスタンスが新しく作成されるが、消えはしないので安全。

 

TerraformとAnsibleの差異

 

最後に、今回の検証を元に、

稻葉様視点で付けたツールの評価についてお話してくださいました。

 

■コード化しやすさ

【Terraform】★★★★

・Terraform import機能があり複雑なリソースもさばける

・動的にIDを取得するのが容易

・JSON慣れしている人には有利

 

【Ansible】★

・AWSモジュール操作の難易度が高め

・importする機能はない

・Ansible慣れしている人には有利（yaml事態は書きやすい）

 

■ 安全性の高さ

【Terraform】★★

・リソース再作成の危険性(知らないと大変なことになる)

・バージョンアップデートで改善されている（インスタンスタイプ変更など）

 

【Ansible】★★★★

・検証中、既存のリソースが削除される挙動はなかった

・手違いで新規インスタンスが立ち上がった場合は課金されてしまう。

■ 冪等性

【Terraform】★★★★

・terraform.tfstateとtfファイルに差分がなければ問題ないが、、、、

・Githubで権限が消失したという言う事例もあったりとまだまだ検証が必要

 

【Ansible】★★★★

・count_tag,exact_countの使用でインスタンスの冪等性問題なし

まとめ

 

稻葉様は今回の検証を最後に次のように結論づけていました。

どこまでできるかというポイントに関しては、AnsibleはTerraformと同じことができます。もちろんAnsibleでも既存リソースが消えるなどの挙動はないのですが、ただplaybookが長く、回りくどい印象があります。また、学習コストも少し高く、Terraformのほうが書きやすいので明らかに少ない工数で使用可能です。インフラ土台構築はTerraformで書いて、その上のミドルウェアはAnsibleでプロビジョニングすると、これが一番幸せなのかなと思います。

 

 

 

 

お菓子おじさんによる［AWS CLI］シェルでAWSサービスの自動構築をやってみた | 當山 翔太 様

 

https://speakerdeck.com/toyamashota/aws-cli-sierudeawssabisufalsezi-dong-gou-zhu-woyatutemita

 

3人目は當山様。

今回はシェルでAWSサービスを自動構築したお話をご紹介していただけました。

 

當山 翔太 様

沖縄出身で7年間ホスティング会社に在籍し、数百台のサーバの障害対応や構築を経験する。
サーバスペシャリスト。
awscliによるシェルスクリプトマスターと言っても過言ではない。
社内のお菓子おじさんでもある。
ももクロとチームしゃちほこがお気に入り。

構成図

 

開発からの依頼のあった当初の構成図がこちら

 

1ドメインにつき1個のクラウドフロント、証明書を使いたいとのことですが、

次のような問題点があったそうです。

問題点

 

・ドメイン数=ロードバランサーが必要

・WEB/APIサーバーがあるので

　1ドメインあたりロードバランサーが2台必要

・上限申請したが50までしか上げてもらえなかった

　50/2=25ドメインまでしか使えない

 

これを解決したた構成図がこちらになります。

 

Cloudfrontは上限緩和申請、ドメイン使いたい分申請はできたが、ロードバランサーの方はできなかったので、Port番号を割り当ててどうにか作成したそうです。

 

赤枠が今回自動化で説明していただいたところとなります。

各サービスの自動化について

 

今回次の3つのサービスの自動化についてお話して頂きました。

 

・ACM(AWS Certificate Manager)

・ALB(Application Load Balancer)

・Cloud Front

Certificate Managerについて

 

Load Balancer＆Cloud Frontに使う証明書の自動化についてお話していただきました。

下記のスライド画像にあるaws acm request-certificateのdomain-nameで、ドメインを指定してあげることで証明書の取得が可能に。

 

証明書を発行するのに対象のドメインに対して承認のメールがAmazonから送られてきて、メールのURLをクリックしてボタンを押す必要があるそうです。

 

 

上記は実際にAmazonからくるメール。

この左上がアマゾンから来るメールで、このメールのURLをクリックしたあとにブラウザを開いて、右下の「I Approve」をクリックすることで証明書の発行ができるそうです。

ACM、証明書の自動化の道のりの手順について

SESにドメインを登録。この対象ドメインをSESで受信できるようにして、SESで特定のドメインに対してメールが受信したらどうするかっていうルールセットができ、こちらのほうでメール受信したら、S3のバケットにこのメールを送ってその後にLambdaでキックさせる。Lambdaの方では何やっているかというと、PythonのWebスクレイピング。PythonのWebスクレイピングに関してはネット上で落ちていたものを改良して利用。最後にMXレコードをSESのメールが受信できるように設定することによってACMの証明書が発行できるそうです。

Application Load Balancerについて

 

こちらはロードバランサーを使用しEC2へ振り分けを行います。もともとアプリケーションじゃなくてクラシックロードバランサーを使っていたので、アプリケーションロードバランサーとしての役割は一切未使用だそうです。ちなみにロードバランサー作成については今回は割愛されています。Portの割当をどのように行っているかについては、完全に使っているロードバランサーをまず調べ、現在使っているPort番号を割り出し、今使っている次の番号を割り振っているそうです。ちなみにロードバランサーは、1ロードバランサーあたり100ポートまでしか使えないので、100ポート達したら次の新しいロードバランサーをつくるっているそうです。

Cloud Frontについて

 

CLIでやる場合はJSONファイルを読み込む必要があります。

aws cloudfront create-distributionで、Cloud FrontのJSONファイルを読み込ませることによってCloudfrontの設定ができる。ただ、JSONファイルは、完全に手動で作ったそうです。

実際最初に手動でCloudfrontをつくってaws cloudfront create-distribution で作ったCloudfrontのIDを呼び出すことによって、Cloudfrontの設定情報を取り出せる。その設定情報を取り出して、一部を取り出してやっているそうです。

JSONファイル

 

実際の内容は以下になります。

 

最終的に作成完成したShellの一部がこちらです。

 

今回當山様が作成したシェルの流れは上記のようになっています。

Route53ドメインが登録されているかをチェックしてSESにドメインを登録します。SESに使うにはRoute53にSESのテキストレコードとDKIMを登録する必要があり、これらを登録。そのあとにSESのルールセットを、S3とLambdaをかませるようなルールセットで登録。次に証明書の発行。Cloudfrontの場合は、バージニアの証明書しか使えないのでCloudfront運用とあとAB用2本、のふたつの証明書を発行。

つぎにロードバランサーの作成、もしくはオートバウンドのとなって最後にCloudfrontの設定してルート53にCloudfrontの情報を登録をして、S3のデータを消したり、MXレコードを本番用に変えるなど雑務処理を行っているそうです。

まとめ

 

・AWS CLIのみで自動化つらい

・AWS CLIマスターになれた（気がする）

・出来るエンジニアの方々は素直に

　CloudFormationやTerraformを使ってください。

 

 

脆弱性検知ツールVULSの導入をしてから半年経ってみて | 安達 涼(あだちん) 様

 

https://speakerdeck.com/rvirus0817/cui-ruo-xing-jian-zhi-turuvulsfalsedao-ru-wositekaraban-nian-jing-tutemite

インフラエンジニアはセキュリティの担保もしなければいけないということで

Vulsの導入についてお話していただきました。

また、それに加えてご自身のチームのマネジメントの体験談もお聞きすることができました。

 

安達 涼(あだちん) 様

1989年生まれ。
2013年新卒インフラエンジニア。趣味で自宅サーバを構築し、
月間数万PVもある技術ブログ(https://blog.adachin.me)を立ち上げた。
當山氏と前職が同じで主に社内SE、ホスティング、アドテクなど様々なインフラを経験しAWSマスターになりたいためITIにジョイン。
現在はメンバーへのタスク管理、レビュー、DevOps/新技術の検証など行っている。
HIPHOPが好きすぎてTrack Makerでもあり、ビジネスマンラップトーナメントのメンバーでもある。

安達様が入社する前

 

安達様が入社される前は上記のような状態。

そこで、Googleが提供しているSREチームとして動かなければならないとお考えになったそうです。

インフラSREチームになってから

 

『サイトリライアビリティエンジニアリング』28章のSREの成長を加速させる方法、「新人からオンコール担当、そしてその先へ」を参考にしたそうです。

 

そして安達様はSREの定義を以下のように定義

 

 

インフラ技術とアプリケーション知識、セキリュティ知識、コミュニケーション能力がSREには求められ、エンジニアに加えて以下の特徴を発揮することが必要とお話してくださいました。

 

1.システムの動作を理解しアプリ側の理解も深め、リバースエンジニアリングのスキルを持つこと

2.統計的に考える能力、分析や比較をし行動できること

3.臨機応変に行動し根本的な原因を発見できること

SREの教育方法

 

 

前述した本に書いてある教育方法についてご紹介して頂きました。右側のアンチパターンとしてやってはいけないことに少し違和感を感じているそうです。基本的には新人たちはまだまだ若く、障害対応などを自分で考えてこれでいけないので、上記のアンチパターンに当てはまっていても行うこともあるそうです。また、作業手順をもとに厳密に従う訓練も悪いものではなく、必要ではないかと仰っていましたが、自分で考える癖がなくなってしまうためアンチパターンに当てはまるのではないのかと仰っていました。

 

 

安達様はインフラSREチームになってから

新人たちに障害対応を任せることで責任感を持たせ、一人前のインフラエンジニアとしても成長させるように仕掛けているそうです。

インフラSREチームの主な業務、利用している技術

 

 

様々な技術を駆使して、上記の業務を遂行しているそうです。

 

Vulsとは、ぶっちゃけ脆弱性対応って...

 

 

安達様がVulsについてお話してくださいました。

VulsとはVULnerability Scannerの略で、フューチャーアキテクトの神戸氏、林氏によって開発されたもので、Linuxサーバーに存在している脆弱性をスキャンすることができるそうです。エージェントレスアーキテクチャ（SSH）で、検知した内容を

実際にEメールやSlackにて、通知することが可能だそうです。

 

 

そのため、めんどくさくて地味な作業の脆弱性対応も、

Vulsを使ってSlackで通知がくるようにするだけで運用がとても楽になり、

現状運営しているサーバもどれくらい脆弱性があるか確認することができるようになりました。

Vuls構成図、インストール方法

 

ITI様での導入事例についてもお話してくださいました。安達様が入社してすぐにVulsを導入しようと考えたそうです。冗長化するZabbix3のスペックが高かったため、Zabbix3にVulsをインストールして各全サーバーのホストをスキャンしようと考えたそうです。Vulsサーバーがスキャンをし、resultディレクトリに全情報がレポートで流れるのでfluentdを使いログ系はサーバで管理もしないようにもしてるそうです。

インストール方法は安達様のブログに書いてあるそうなので是非御覧ください。

https://blog.adachin.me/wordpress/archives/5540

config.toml、Vulsコマンドについて

 

Vulsを使って、slackで脆弱性を通知する仕組みを実際にどうやって設定したかをご説明して頂きました。

VulsRepoで労働エラーが起きて2週間解決することができなかった時、カスタマーサポートへ連絡して、新しいバージョンがリリースされることをお知りになったとか。

 

Vuls Repo Vuls v0.4.0・・・・・

 

 

続いて、8月25日にリリースされたVulsの0.4.0についてご紹介して頂きました。

Vulsの0.4.0では次のことが変わったそうです。

スキャン精度が大幅に向上し、「？」が減る。レポートの情報量アップ。

fast(sudoなし、サーバー低負荷のスキャンモード)がデフォルトに。

また、Vuls Repo最新ではWebサーバーを持たなくても良くなりました。

Goのhttpパッケージでダイジェスト認証も簡単に使うことが出来ます。

 

次に、脆弱性をアップデートするフローについて解説して頂きました。

 

インフラエンジニアの誰しもが悩む、どこまで脆弱性対応すればいいのか問題については次のようにお話してくださいました。正直アップデートするのは荷が重いと、特にKernelの再起動が多い。直接第三者が攻撃しやすそうなサーバーなどマストでアップデートしているそうです。例えばLBにぶらさがっているものなど。AWSは基本的にセキュアであり、ITI様は脆弱性0を目標にし、すぐにアップデートをしていいるそうです。他にも新しい脆弱性が出てて未知のものも沢山あるとか。結果的には脆弱性のアップデートはじゃんじゃんしたほうが安心とのことです。

 

まとめ

 

安達様は最後に次のようにまとめていました。

Vulsの導入は簡単で運営も改めて見直すべき。

一番めんどくさいことをVulsによって楽にしてくれる。

Vulsのおかげで脆弱性対応も忘れることがない。

これからVuls必須になりそうとのこと。