Splunkと各種ツールによるAWSの管理

エクセル管理から抜け出せ
Splunkと各種ツールによるAWSの管理
フォージジョン株式会社
http://www.forgevision.com/
All rights reserved, Copyright ForgeVision, Inc.
【GOJAS Meetup-03】SplunkケーススタディVol.2
2017-04-14

All rights reserved, Copyright ForgeVision, Inc. 22017-04-14
自己紹介
フォージビジョン株式会社
山口正徳 @kinunori
エンジニアリングマネージャ、
インフラエンジニア
AWS認定ソリューションアーキテクトプロフェッショナル、
CISSP
プリンシパルエンジニア兼マネージャ

アジェンダ
背景と課題
課題解決への取り組み
なぜSplunkを選んだのか
今後の展望
まとめ

背景と課題

背景
52017-04-14
各エンジニアチームごとに必要な環境を構築できること
Webサービス開発 (PHP、Javascript、Java、Python)
スマートフォンアプリ開発 (Swift、Java、Unity)
VRコンテンツ・アプリケーション開発 (Unity、Google VR SDK など)
インフラ系サービス (インフラ構築、Splunk構築支援サービスなど)
必要な時に必要なだけのサーバリソースを各チームで利用可能であること
当初は OpenStack と Vmware のオンプレミスを中心に利用していた為、
サーバリソースを増やすには物理サーバの増設が必要だった
管理するサーバ台数とインフラエンジニアに掛かる運用負荷が
比例してしまう状況は避けたかった
⇒これらの要求に応えるため、AWSへ移行を検討開始。
アカウントを分ける事で環境間の影響を抑える事も可能と判断。
AWSのマネージドサービスを利用する事で管理負荷低減も期待。

背景
62017-04-14
コミュニケーションツール
Slack
タスク管理
Redmine、Backlog(タスク管理、ナレッジ管理)
バージョン管理
Subversion
Git
監視(環境・レイヤによって使い分け)
Nagios
Mackerel
ログ管理(統合中)
Splunk
Fluentd + Elasticsearch + Kibana
Norikura
rsync + tmux + Pythonスクリプト

利用状況(開発環境のみ)
72017-04-14
EC2インスタンス
70
Elastic Load
Balancing
8
S3 バケット
180
Lambda
10
RDS
12
Dynamo DB
3
SQS
80
VPC
9
他にもサービスは複数利用

開発チームとインフラチームの責任範囲
82017-04-14
スクラム導入
プルリクエストベース開発
テスト自動化
継続的インテグレーション
インフラチーム
アプリケーション実行環境
メンテナンス、チューニング
運用・監視(安定稼働)
継続的デプロイ化
開発チーム(開発速度、品質改善の工夫)
サービス
・
成果物
ユーザ・顧客

スクラム導入
テスト自動化
開発チームとインフラチームの責任範囲
92017-04-14
サービス
・
成果物
ユーザ・顧客
＜共通目的＞
顧客へ価値を届けるまでの
リードタイムを短くする

開発工程におけるインフラに関連する作業の一例
102017-04-14
インフラエンジニア開発エンジニア
要求
(割り込み)
作業適用
開発環境
(プロダクション環境)
依頼作業
提供
オーバーヘッド
になり得る時間

開発工程におけるインフラに関連する作業の一例
112017-04-14
インフラエンジニア開発エンジニア
～が必要
割り込み
作業適用
開発環境
依頼作業
提供
オーバーヘッド
になり得る時間
インフラエンジニアが
価値提供(イノベーション)の
妨げにならない仕組みが必要

イメージ
122017-04-14
開発エンジニア
要求
介在する
頻度を最小
適用
開発環境
実行処理
提供
プログラム
・
ツール
提供

課題
132017-04-14
いわゆる DevOps を支える仕組み作りが必要と判断
AWSをChatツールのインタフェースから操作/情報取得
Lambda + Slash Command で Slack から EC2インスタンスの操作を実行
S3バケットの一覧を表示
サーバ構成をコードで抽象化(Infrastructure as Code)
サーバ(OS、ミドルウェア)構成を Ansible + Serverspec を用いて
宣言的な記述で定義 (AWSは terraform で構成管理)
バージョン管理(Git)を利用する事でソフトウェア開発のプラクティスを
インフラにも流用
サーバをJenkinsからデプロイ
Jenkinsにジョブを定義しパラメータ変更でサーバ自体をデプロイ
インフラの継続的インテグレーションも実現
⇒ 開発者自身が必要な時に、必要なインフラの操作を実行可能

AWSをChatツールのインタフェースから操作/情報取得
142017-04-14

なぜSplunkを
選んだのか

ID
が欲しい
Elastic IP(ENI)の
情報が欲しい
セキュリティ
グループで
絞り込んだ情報が
欲しい
EBSの情報が
欲しい
ID
が欲しい
EBSの情報が
欲しい
162017-04-14
タグで絞り込んだ
情報だけじゃない
と効率が悪い
セキュリティ
グループで
絞り込んだ情報が
欲しい
CSV出力したい
EBS最適化ではない
インスタンスだけ絞
り込みたい
AMI ID
が欲しい
Vulsの対象か
知りたい仮想化タイプ
の情報が必要
セキュリティ
グループの情報を
キーに抽出したい
Elastic IP(ENI)の
情報が欲しい

新たな課題
172017-04-14
動的に変わる情報を必要な時に必要な角度で取得する
基本はSlackで
Slackで対応出来ない場合は AWS CLI で取得してもらう
JSONのデータ構造を見て、query/filter もしくは jq で抽出するのは
手間と時間がかかる
AWS利用コスト管理
無駄なリソースが残存していないかチェックが必要
クラウドの拡張性・柔軟性を壊さない監査の方法
インスタンス台数など動的に変わる環境をエクセルなど従来のような
台帳管理ベースで監査するのは困難
現在の構成はAWS上にある、AWSからAPIで取得すればいい
ただし、過去の情報は取得できない。AWS Configという手もあるが、
全網羅的に確認することは難しい(全体監査からの詳細調査には便利)

Splunk App for AWSを検討した結果
192017-04-14
動的に変わる情報を必要な時に必要な角度で取得する
基本はSlackで
Slackで対応出来ない場合は Splunk にサーチマクロを用意しておき、
必要時に検索してもらう
JSONオブジェクトをフィールドとして認識してくれるので
データ構造を理解する必要はなく、直感的に抽出可能。
Queryや jq で
(.Reservations[].Instances[][.InstanceId, .PublicIpAddress])
とか不要
AWS利用コスト管理
無駄なリソースが残存していないかチェックが必要
プリセットされているダッシュボードで不要なリソースを視覚的に
確認可能になった
AWS Config Ruleで監査している項目と準拠、非準拠とあわせて
あわせて確認することもできるのでルール見直しも効率化

Splunk App for AWSを検討した結果
202017-04-14
クラウドの柔軟性を壊さない監査の方法
インスタンス台数など動的に変わる環境をエクセルなど従来ベースの
台帳管理で監査するのは困難
現在の構成はAWS上にある、AWSからAPIで取得すればいい
Splunk App for AWSは指定した間隔でAPIリクエストを発行し、
その時の構成情報を保持するので特定ポイントでの構成確認も行いやすい
エクセル化が必要な場面でも、抽出する内容を指定して Tableコマンドで
整形した後、CSV出力することで無駄な労力を使わない
AMIは Packer で、設定管理は Ansible で、AWSは Splunkで
それぞれのレイヤでの構成管理が出来る
Splunkの導入コスト
フリーライセンスでも利用できる範囲
(ただし自分たちで問題解決する覚悟は必要)

Splunk App for AWSで取得できる情報
212017-04-14

Splunk App for AWSで可視化できること
222017-04-14
全て挙げると膨大になるのでメインで使っているものを一覧
(青字は高い頻度で利用しているもの)
• VPCトポロジ
• Security Group / NACL
• ENIにアタッチされていないSecurity Group
• 各ルールのアクティビティ(VPCフローログとの組み合わせ)
• EC2/ELBインスタンス利用状況、標準メトリクス ※
• EBSボリューム利用状況、標準メトリクス ※
• RDS標準メトリクス ※
• AWS Config/Config Rules 統計情報
• S3トラフィック分析
• KeyPair 利用分析
• 請求情報

Overview (AWS Config)
232017-04-14

242017-04-14

252017-04-14

Overview (AWS Config / Config Rule)
262017-04-14

AWS Config / Config Rule
272017-04-14

AWS Config / Config Rule
282017-04-14

エクセル対応
292017-04-14

エクセル対応
302017-04-14
# aws ec2 describe-instances | jq -r '(["id", "ip_address", "private_ip_address", "instance_type", ¥
"Name"]), (.Reservations[].Instances[]|[.InstanceId, .PublicIpAddress, ¥
.PrivateIpAddress, .InstanceType, (.Tags[]|select(.Key=="Name").Value)]) | @csv‘
"id","ip_address","private_ip_address","instance_type","Name"
"i-xxxxxxe",,"10.100.150.230","t2.micro","Ansible_test_ins"
"i-yyyyyy4",„52.1xx.2xx.3x","10.100.150.80","t2.medium","Splunk-Server"
. . .
{
"Reservations": [
{
"OwnerId": “XXXXXXXXX",
"ReservationId": "r-xxxxxxxe",
"Groups": [],
"Instances": [
{
"Monitoring": {
"State": "disabled"
},
"PublicDnsName": "ec2-xx-xx-xx-xx.ap-northeast-1.compute.amazonaws.com",
"State": {
"Code": 16,
"Name": "running"
},
"EbsOptimized": false,
"LaunchTime": "2017-04-12T15:10:03.000Z",
"PrivateIpAddress": "10.100.150.80",
どの情報が欲しいかjsonの
データ構造を見て抽出する

スクラム導入
テスト自動化
開発チームとインフラチームの責任範囲(P.8より再掲)
312017-04-14
サービス
・
成果物
ユーザ・顧客
＜共通目的＞

スクラム導入
テスト自動化
Splunk App for AWS 導入による効果
322017-04-14
サービス
・
成果物
ユーザ・顧客
Splunk App for AWS
を採用することで
車輪の再発名のような作業を抑え
本質的な仕事に集中する
↓
＜共通目的＞

今後の展望

今後の展望
342017-04-14
lambda Function(Step Functions)の実行ログをSplunkに集約
CloudWatch Logs -> S3 -> Amazon Athenaと比較
Amazon EC2 Systems Managerとの連携
EC2インスタンスのインベントリ情報(パッケージ、ライブラリなど)を
Splunkに集約し開発エンジニアが手間をかけずに確認できるようにしたい
パッチ管理を集約
キャパシティプランニングの自動化
App for AWSの機能としては存在する
プロダクションと開発で異なる軸をどう吸収していくか
EC2 リザーブドインスタンスの分析
現在リザーブドインスタンスの情報が取得できない？(調査中)

まとめ

まとめ
362017-04-14
きっかけは課題解決の為 DevOps を支える仕組み作りが必要な状況から
自動化、Slack連携、Infrastructure as Code
インフラの継続的インテグレーション
柔軟性が低く、動的な環境には耐えきれない状態が発生
動的に変わる情報を必要な時に必要な角度で取得
クラウドの拡張性・柔軟性を壊さない監査の方法
Splunk App for AWSの採用を検討
JSONオブジェクトをフィールドとして認識してくれる
プリセットされているダッシュボードで不要なリソースを視覚的に
確認可能
構成情報を保持するので特定ポイントでの構成確認も行いやすくなった
各レイヤの構成管理ごとにツールを使い分けている

372017-04-14
お問い合わせはこちらまで
AWSに関するご相談
Splunkに関するご相談
splunk-proj@forgevision.net
弊社 Splunkエンジニア、
AWS認定エンジニアが対応致します。

382017-04-14
We’re hiring！
一緒に働くエンジニア募集中！！
Re:invent 2016 エンジニアブログ
http://techblog.forgevision.com/
興味がある方は、 http://forgevision.com/contact/ からご連絡ください！！！１

Splunkと各種ツールによるAWSの管理

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Splunkと各種ツールによるAWSの管理

Similaire à Splunkと各種ツールによるAWSの管理 (20)

Splunkと各種ツールによるAWSの管理