Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
6gram to MIXI M / 6gram から MIXI M へ 〜2年間の軌跡〜
Search
ryosan470
July 01, 2022
Technology
2
780
6gram to MIXI M / 6gram から MIXI M へ 〜2年間の軌跡〜
ミクシィ x ビットバンク合同LT会 〜2社におけるクラウド活用最前線〜
https://mixi.connpass.com/event/251707/
にて登壇した内容のスライドです。
ryosan470
July 01, 2022
Tweet
Share
More Decks by ryosan470
See All by ryosan470
グループウォレットアプリ6gramの運用をはじめてみた / 6gram SRE NEXT 2020
ryosan470
6
12k
Our monitoring past and future tale
ryosan470
3
1.3k
the background of mixi git challenge
ryosan470
1
320
新米SREとしての半年
ryosan470
1
2.8k
Other Decks in Technology
See All in Technology
JSON攻略法.pdf
miyakemito
8
4.9k
Azure犬駆動開発の記録/GlobalAzureFukuoka2024_20240420
nina01
1
210
継続的な改善 x ⾮連続的な進化
sansantech
PRO
3
150
Compose Compiler Metricsを使った実践的なコードレビュー
tomorrowkey
1
220
Vertex AI を中心に 生成AIのアップデートを共有します
kaz1437
0
300
推しは推せるときに推せ! プロダクトにフィードバックしていこう
nakasho
0
290
ServiceNow Knowledge Learning Rise up
manarobot
0
210
コードを書く隙間を見つけて生きていく技術/Findy 思考の現在地
fujiwara3
27
5.9k
チームでロジカルシンキングに改めて向き合っている話 〜学習環境と実践⽅法〜
sansantech
PRO
2
2.1k
MapLibreとAmazon Location Service
dayjournal
1
150
DevOpsDays History and my DevOps story
kawaguti
PRO
9
2.5k
一生覚えておきたい「システム開発=コミュニケーション」〜初めての実務案件振り返りLT〜
maimyyym
0
120
Featured
See All Featured
Documentation Writing (for coders)
carmenintech
60
3.9k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
78
42k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
2
1.3k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
187
16k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
6
1.5k
Building an army of robots
kneath
300
41k
Designing for Performance
lara
601
67k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
241
1.2M
Ruby is Unlike a Banana
tanoku
96
10k
Learning to Love Humans: Emotional Interface Design
aarron
267
39k
The Mythical Team-Month
searls
216
42k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
125
32k
Transcript
開発本部 / MIXI M事業部 6gram から MIXI M へ ~2年間の軌跡~
ミクシィ x ビットバンク合同LT会 〜2社におけるクラウド活用最前線〜 @ryosan-470 2022/07/01
SRE NEXT 2020 でお話ししたことの続き 2 「グループウォレットアプリ6gramの運用をはじめてみた」で調べてみてね
今日お話しすること • 構成について • 前提条件と運用目標 • PCI DSS とは何? •
2年経って最初の運用ポリシーやモットーは守れた? • まとめ 3
構成について • AWS 環境に構築 ◦ 東京リージョンのみ ◦ Direct Connect を使っている
▪ データセンター3ヶ所にルーターを設置 • バックエンド: Elixir 4
前提条件 • カード情報を取り扱うために PCI DSS に準拠 • 無停止 ◦ 弊社都合のメンテナンスは基本的には行わない
• 専属の運用チームや運用者は用意しない ◦ インフラ専任者はいない ◦ みんなでワイワイやっていこうというチームの雰囲気 5
「できる限り運用負荷を減らしたい」 6
運用負荷とは? 7 • 例えばインスタンスが存在すると: ◦ ホスト OS の管理やカーネルパッチアップデート • セキュリティ対策
◦ ウイルス、脆弱性、侵入検知、ファイル改ざん...
運用負荷とは? 8 • 例えばデータベースサーバー (RDBMS) が存在すると: ◦ スケーラビリティ ▪ 水平方向に増やすのは厄介
▪ 自由に伸縮すること • 無停止オペレーションの実現の困難さ ◦ マイグレーション ▪ 大きいテーブルになると無停止では難しい ◦ RDBMS 自体のメンテナンス
行き着いた構成 9
完全フルマネージド、サーバーレスな構成 10 AWS Fargate AWS CodeBuild AWS Lambda コンピュート Amazon
DynamoDB データベース Amazon CloudWatch Rollbar ロギング
この構成は PCI DSS 準拠を行うのも楽 • 多くの要件を AWS に任せることができる ◦ インスタンスが存在しないことで「アカウント」の要件がなくなる
• 例えば: ファイル改ざん ◦ ホストマシンは AWS 管理下なので考慮不要 ◦ 動いているコンテナを読み取り専用に 書き込めないんだから改ざんできるわけない 11
PCI DSS とは? • クレジットカード情報を取り扱う事業者が遵守する規則 • 12要件約400項目ある • 毎年 QSA
と呼ばれる外部の監査人から監査を受ける ◦ 規模によっては自己問診というのでも OK ◦ 弊社は外部監査を受けています。 • 時代遅れみたいな要件もある ◦ 例: パスワードは90日ごとに変更 12
ここまでが2020年当時の話 13
気になるところ 14 • セキュリティインシデントはなかったのか • データベース、DynamoDB 全振りで OK だったのか •
2年間で構成に変化はなかったのか • 2年間インスタンスがなくても問題なかったのか
気になるところ 15 • セキュリティインシデントはなかったのか • データベース、DynamoDB 全振りで OK だったのか •
2年間で構成に変化はなかったのか • 2年間インスタンスがなくても問題なかったのか
「セキュリティインシデント」 はありませんでした!!! 16
気になるところ 17 • セキュリティインシデントはなかったのか • データベース、DynamoDB 全振りで OK だったのか •
2年間で構成に変化はなかったのか • 2年間インスタンスがなくても問題なかったのか
問題なし 18 時間の都合で詳細はカットします
気になるところ 19 • セキュリティインシデントはなかったのか • データベース、DynamoDB 全振りで OK だったのか •
2年間で構成に変化はなかったのか • 2年間インスタンスがなくても問題なかったのか
2020年初頭に監査人から一言 20
監査人からのコメント 21 • ルーターのログ、保存している? ◦ ログサーバーまたは別媒体に即座にバックアップ • ルーターの時刻同期してますか? ◦ 信頼できる時刻ソースと同期
• ルーターのコンフィグ管理をしていますか?
来年 (2021年) の監査までには解決してね 22
どうにかせねば 23
データセンター (2020年当時) の状況 24 • ログはルーターの中に保存しているだけ ◦ 何か間違えたりバッファが溢れると消えてしまう可能性があった • 時刻同期はしていない
◦ 信頼できる時刻ソースとは同期しておらず ◦ データセンター内にある弊社別チームの時刻サーバーと同期 • コンフィグ管理はできていない ◦ GitHub で設定されているコンフィグを管理 ◦ 実際にそれ通り設定されているか作業者以外が確認できない
なんとかせねば... いろいろと検討と調査をすすめる • CloudWatch は直接ログを受けることができない ◦ エージェントが必須 • AWS には
NTP サーバーが存在するが Direct Connect 経由からは直接接続できない ◦ NTPサーバーを買うという手もある 上2点は UDP プロトコルを受けられれば何かできる • ルーターには「HTTPアップロード」という機能がある 25
どうしよう... • Network Load Balancer は当時 UDP を受けられたが バックエンドにインスタンスが必要 このために運用負荷が増えるインスタンスの導入はやり
たくない • NTP は TCP でも何とかなりそうだがあまり一般的では ない • コンフィグに関しては「HTTPアップロード機能」で何と かできそう 26
行き詰まった 27
そんなとき 28
Fargate が NLB + UDP のロードバランシングサポートを発表 (2020/07) 29 • ログ
◦ Syslog サーバーを Fargate で稼働 ◦ 受け取った値をそのまま標準出力 → CloudWatch • 時刻同期 ◦ AWS の時刻ソース (Amazon Time Sync Service) にプロキシ ◦ 時刻ソースは原子時計なので信頼できる • コンフィグ ◦ HTTP サーバーを構築 → CloudWatch
2021年の監査: 「問題なし」 30
一件落着 31
気になるところ 32 • セキュリティインシデントはなかったのか • データベース、DynamoDB 全振りで OK だったのか •
2年間で構成に変化はなかったのか • 2年間インスタンスがなくても問題なかったのか
結論 必要になりました 33
JCB に続き Visa の導入が決まった 34
仕様書などを眺めてみる 35 • ほとんど今までの構成で動きそう • ただ提供されるソフトウェアが以下でしか動かない ◦ Windows Server ◦
メインフレーム
Windows !? 36
Windows の懸念 37 • そもそもデスクトップ版しか触ったことがない • どうやって運用するのかすら不明 • インスタンス必要では?
インスタンスを利用しないで済む方法はないだろうか? 38 • CodeBuild ◦ Windows 対応 ◦ そもそも提供されるソフトウェアが GUI
必須 • Fargate ◦ Windows 非対応 ▪ 今は利用できるが GUI はおそらく非対応 (未検証)
諦めて「インスタンス」を導入することに 39
インスタンスがあると何をしないといけないのか 40 • Windows アップデート • 脆弱性検知 • ファイル改ざん検知 •
リアルタイムウイルススキャン • 管理アカウントのパスワード
さらにインスタンスの運用負荷をできる限り下げたい 41 • 構成管理はコードで管理できないのか • セキュリティパッチ適用の自動化 • インスタンスのログを CloudWatch に集約
• GUI アプリケーションを何とかできないか ◦ バッチ実行
いろいろがんばりました... 42
Windows アップデート、セキュリティパッチの自動適用 43 • AWS Systems Manager - State Manager
を利用 ◦ パッチが配信されたら自動適用 ◦ 毎日、Windows アップデートが配信されているかを確認
脆弱性検知 • Amazon Inspector を採用 ◦ 毎日定時に Inspector を起動して脆弱性確認 •
実行結果はすべて Slack に通知 44
ファイル改ざん検知 • osquery をデーモンとして動かす ◦ 事前にファイルが書き込まれる場所を定義 ◦ 書き込みログをすべて CloudWatch に集約
◦ メトリクスフィルターで許可していない挙動を監視 ▪ Slack に通知 45
その他 • ウイルススキャン ◦ Windows Defender • Windows Server のイベントログなど
◦ CloudWatch のログエージェントにより記録 46
その他 • 管理アカウント ◦ パスワードは固定 ◦ 閲覧には権限が必要 ▪ 閲覧者は操作記録が CloudTrail
から確認可能 ◦ RDP は Session Manager の機能で利用 ▪ 誰が RDP をしたか特定可能 47 固定パスワードでも安全性を担保
構成管理について • Ansible を採用 ◦ Chef も候補だったが Ruby の依存を嫌って不採用 •
VPC 内に CodeBuild を用意しそこから Ansible を適用 ◦ 踏み台インスタンスを不要に • インスタンスの構成自体は CloudFormation で定義 ◦ インスタンスタイプ ◦ ネットワークインターフェース 48
GUI アプリケーションについて • 設定に関しては GUI を利用する必要がある • バッチ処理の実行は BAT ファイルからもできる
• 実行ログは特定のディレクトリの特定のファイルに書き 込まれる仕組み 49
そこで、BAT ファイルを呼び出すエージェントを作成 • エージェントが HTTP で待ち受ける ◦ リクエストを受けるとエージェントが BAT ファイルを実行
◦ ログを CloudWatch に転送 ◦ VPC内でのみアクセスを受け付けるような設定 • 定時処理 ◦ CodeBuild からエージェントへ HTTP リクエストを行う 50
何とかインスタンス動いた 51
監査も問題なし 52
Windows インスタンス導入編のまとめ • 意外と Linux インスタンスに近い構成で運用できる ◦ だがそこまで Windows の機能を使っていないだけだからかも
◦ 台数も1台しか管理していないし... • AWS Systems Manager はいろんな機能がある ◦ Fleet Manager で設定されているレジストリをみて編集できる ▪ 特定のレジストリを設定する必要がある時にいちいち RDP しなくてよい ◦ Session Manager の RDP はWebブラウザ経由でできるようになった ▪ リモートデスクトップクライアントは不要 • 構成管理は重要です ◦ 構築後に誤ってインスタンスを壊したこともあったが簡単に再構築 53
全体のまとめ • 構成は大きく変わらずにすみました • 完全フルマネージド、サーバーレス構成オススメ • クラウド環境外のリソースのことを忘れがちなので注意 ◦ しっかり構成図を書いておくことよいです •
構成管理はしっかりやろう 54