tec_tec_blog

いちSEの日々の興味のあるところを取止めなく

JustTechTalk#09に参加してきました

2017年06月30日にありました、
JustTechTalk#09 Webサービスを支える「インフラ」の運用事例とベストプラクティス
に参加してきました。

※資料は公開され次第、リンクを追記します

最近、AWSを活用するケースが多いと思うのですが、やり方が多く、

どうするのが良いのか迷う場面が多くなりましたので、その一助になれば良いかと思い、参加です。

 

justsystems.doorkeeper.jp

特に、案内の中にもあった、

運用テーマ
AWSセキュリティ要件を考慮した最適構成
AWS構築/デプロイの自動化
AWSコストダウンと自動バックアップ
・早期発見/復旧でAWSシステム安定運用

運用ツール
・Ansible/Packer/Terraform/Fluentd
・GitLab/Jenkins
AWS CodeDeploy/
AWS CloudTrail/ColudWatch/EC2 Systems Manager
AWS Athena
・Zabbix

あたりの話を聞きたかったのです。

JustTechTalkへの参加は初めてでしたが、参加者の年齢層は結構バラバラ

若い人たちばかり、、といった感じではなかったです。

その分、地に足ついた内容といった印象を受けました。

 

①DevOpsをどのように進めたか
元々は開発部門と基盤・インフラ部門が分かれていた
→組織改編があり、詳細設計・開発構築時には同じ組織になった。
ただし、そうなると、インフラ担当がアプリケーションの中を理解する必要がある。
開発部門も同様に、インフラのことを知らなければいけない。
→結局組織は一つだが、なんとなく担当は別れるので、結局、仲を取り持つ、

両方(インフラとアプリ)を知っている人が重要。

チーム一体化のデメリット
→管理者、評価者が管理、理解する範囲は増え負担が増える

AWS管理のポイント:AWSアカウントは単一だと危険。
カオスになってくる。(セキュリティグループ、IAM、ACL,,,)
作業ミスで破壊される可能性。

 

terraformでAWSの構成を作成。
→terraformは状態ファイルを持つため。手作業で基盤を変えた場合は差分が発生するため注意
Ansibleなどツール自体の不具合に注意。まだまだある。Bug情報をwatchする必要あり。(これは何にしても、、ですが、)

ユースケース、パラメータ的網羅テストもアプリケーション同様に考え、テストを実施する

今後はログの調査、分析の簡易化、仕組み化を便利にするように推進中。
Amazon CloudwatchLogis,Kibana,を利用。
現状はzabbixを使っていて問題は発生していないが、ノウハウをもっている人に依存してしまっているという課題を認識しており、makalel等に移行するかを検討中。

 

AWS運用における最適パターン
「サービスの責任はアプリケーション開発者が持つ」
梵字徹底:当たり前のことを確実にやる
AWSのベストプラクティスを参考に、実践例も交えて検討する。
コードで確実に、同じ結果にすることが大切

AWS構築、デプロイの自動化
JenkinsからGitLab-CIに。Dockerベースなので良い。(自分にはその良さがわかりませんでしたが)
導入コストが低く、保守も簡単。たまにバグを踏むとのこと。。

 

③ログ管理のベストプラクティス

AWS桑野さん(前職はCA)

CloudWatchLogs,CloudTrail:APIを操作を記録するサービス。
管理コンソール、APIなどが対象。誰がいつAPIを発行したのか、されたのか。

リアルタイム処理が不要であれば、バッチ処理
必要であれば、Streamで処理。
ログ収集サーバに集めるとそこがSPOFになるしスケールしづらい。そこでミドルウェアアプリケーションの利用:Fluentd, Logstatsh, Flume。
バッファリングしてくれるFluentd(OSS)が便利。
Fluentdを多段で組むのが基本スタイルとなる。Aggregation Serverを中間に立てるイメージ。

Kinesis FirehouseでFluentd→S3の連携をEC2無しに実現。
今年のAWS Summitで後2ヶ月ぐらいで東京リージョンに来ると発表されていたので、もうすぐ使えるようになるはず。
直接送れば Aggregation Server不要でシンプルな構成に。Aggregation Serverのスケールアウトも気にしなくていい。

ただしKinesisからログを取得するにはLambdaかEC2が必要→そこで Kinesis Firehose!

Fluentdから直接S3に送ると変更するのが大変、特に書けなかったときのリトライ処理が面倒。


全てのログをS3に貯め続けることが大切。データレイク化の発想。
Amazon athena:S3においたデータに直接SQL実行可能
tokyoでも最近から利用可能になった。
スキャンしたしたデータ1TBあたり5ドルだが、一度スキャンしたものをまたS3に入れて

それを見たり、それからRedShiftで活用したりと節約ポイントはある模様。

 

まとめ

現場でどうやっているか、何に困ってどう対策したかなどが、かなり勉強になりました。開催ありがとうございました。