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
2.1k
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
14k
Our monitoring past and future tale
ryosan470
3
1.4k
the background of mixi git challenge
ryosan470
1
360
新米SREとしての半年
ryosan470
1
2.9k
Other Decks in Technology
See All in Technology
AIエージェント時代のエンジニアになろう #jawsug #jawsdays2025 / 20250301 Agentic AI Engineering
yoshidashingo
8
3.1k
生成 AI プロダクトを育てる技術 〜データ品質向上による継続的な価値創出の実践〜
icoxfog417
PRO
5
1.9k
設計を積み重ねてシステムを刷新する
sansantech
PRO
0
150
(機械学習システムでも) SLO から始める信頼性構築 - ゆる SRE#9 2025/02/21
daigo0927
0
260
【詳説】コンテンツ配信 システムの複数機能 基盤への拡張
hatena
0
210
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
18k
ESXi で仮想化した ARM 環境で LLM を動作させてみるぞ
unnowataru
0
160
Oracle Database Technology Night #87-1 : Exadata Database Service on Exascale Infrastructure(ExaDB-XS)サービス詳細
oracle4engineer
PRO
1
110
Windows の新しい管理者保護モード
murachiakira
0
200
あなたが人生で成功するための5つの普遍的法則 #jawsug #jawsdays2025 / 20250301 HEROZ
yoshidashingo
2
240
Exadata Database Service on Cloud@Customer セキュリティ、ネットワーク、および管理について
oracle4engineer
PRO
2
1.5k
ディスプレイ広告(Yahoo!広告・LINE広告)におけるバックエンド開発
lycorptech_jp
PRO
0
280
Featured
See All Featured
Rebuilding a faster, lazier Slack
samanthasiow
80
8.9k
Agile that works and the tools we love
rasmusluckow
328
21k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
46
2.3k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
A Tale of Four Properties
chriscoyier
158
23k
Music & Morning Musume
bryan
46
6.4k
Git: the NoSQL Database
bkeepers
PRO
427
65k
VelocityConf: Rendering Performance Case Studies
addyosmani
328
24k
GraphQLとの向き合い方2022年版
quramy
44
14k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.2k
Site-Speed That Sticks
csswizardry
4
400
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