楽天市場ローンチ初期から 20 年続くレガシーなバックアップ環境が最新のストレージ技術により一新されようとしています。本セッションでは、楽天でのバックアップの全体像や、Azure のストレージ技術、関連する OSS がどのようにレガシーからの脱却に貢献しているのかについて、現場での運用に基づいた事例としてご紹介します。 受講対象: ツールやSDK、ライブラリのコードを読み書きし、積極的に運用を改善していく「新しい」Opsの生の声を聴きたいインフラ技術者、アーキテクトの方はぜひご参加ください。 製品/テクノロジ: DevOps/Linux/Microsoft Azure/OSS/アーキテクチャ/クラウド/運用 佐々木 健太郎 楽天株式会社 Global Operations Department Cloud Infrastructure Engineer

1. 楽天のクラウドストレージ使いこなし術
Azure と OSS で少しずつ進めるレガシー脱却
Kentaro Sasaki
Cloud Infrastructure Engineer,
Global Operations Department,
Rakuten, Inc.

2. 2
Kentaro Sasaki
Biography:
Specialty:
分散ストレージ、OpenStack、etc.
インフラエンジニア @ Rakuten, Inc.
非常勤講師 @ NII

3. 3
Tokyo-based e-commerce and Internet company

4. 4

5. 5
このセッションの
ゴール
実ユーザの体験談を知る
• 導入イメージを掴む
Azure, OSS, Give & Take and more.
• 使いこなすと何なのか
https://goo.gl/Lz6zEx

6. 6
本日お話したい 3 つの内容
1. クラウド成功パターン (楽天のケース)
オンプレを利用してるユーザが上手くパブリッククラウドを使いこなすには?
2. バックアップの話
市場ローンチ時からあるレガシーシステムは如何にして僕らの眠りを妨げるのか
3. Dev, Ops and more.
OSS 開発や Azure SDKs へのフィードバックなど

7. 7
クラウド導入における成功パターン
オンプレを利用してるユーザが上手くパブリッククラウドを使いこなすには?
1st SECTION

8. 8
パブリック・プライベート両方知る立場から…
クラウド導入を成功させるために必要な要素とは?
On-premise Object Storage Public CloudPrivate Cloud
https://goo.gl/l9HnMF

9. 9
短時間で効果を可視化出来る
スモールスタート
オンプレの方が安い場合もある
コストメリット
自前で用意するのは難しい
マネージド
3 IMPORTANT
KEYWORDS
01 02
03

10. 10
これら 3 つの要素を踏まえた上で…
どのサービスから使い始めるのがよいのか?

11. 11
クラウドストレージ
Block Blobs in Azure Storage
個人的なオススメはコレ

12. 12
Block Blobs とは
一体何なのか?
写真のデータ、バックアップに最適
• オブジェクトストレージ
月あたり ¥1.64/GB (LRS-COOL)
• めちゃくちゃ安い
https://goo.gl/EfupHr

13. 13
Block Blobs なら 3 つの要素を容易に満たせる

14. 14
1. スモールスタート

15. 15
システムにスモールに組み込める
小さく始めることができて辞めるのも簡単

16. 16
2. コストメリット

17. 17
短時間で実現可能で低コスト
GB 単価が安く、導入後すぐに成果を可視化することが出来る

18. 18
3. マネージド

19. 19
運用しなくてよい
ストレージの自社運用は総じて大変である

20. 20
Block Blobs を活用できる使い方とは?

21. 21
成功パターンの 1 例
テープバックアップからの脱却
小さく始めることが可能
https://goo.gl/wYJZXA

22. 22
20 年間動いているテープバックアップのお話
市場ローンチ時からあるレガシーシステムは如何にして僕らの眠りを妨げるのか
2nd SECTION

23. 23
https://goo.gl/cpzgeG
テープを減らす
レガシーからの脱却

24. 24
テープ運用の大変なところ

25. 25
倉庫の運用が大変
移送、リストア対応
https://goo.gl/gzsSMV

26. 26
HW 障害が大変
ドライブがテープを巻き込んで壊れる
(半年に 1 回程度)
https://goo.gl/PCBeWR

27. 27
テープ管理が大変
廃棄処理をする必要がある
(年 1 回、1000 本ほど)
https://goo.gl/gVZUHs

28. 28
クラウド利用で良くなるところ

29. 29
物理コンポーネントの排除
HW トラブルに対する対応時間を極小化できる

30. 30
倉庫管理工数の削減
とはいえ、工数ゼロにはできない

31. 31
DR (Disaster recovery) の実現
自社 DC 群と Azure のリージョンとの間で DR ができるようになる
自社 DC 群
東日本リージョン

32. 32
楽天の場合…

33. 33
保管対象とセキュリティー
1. 楽天(株)本体のデータ
楽天市場・会員ID / スーパーポイント などの共通基盤など
2. 楽天銀行、楽天Edy、楽天生命の一部データ
テープ保管倉庫内の保管区画も分離されている
3. セキュリティーポリシー
各種法令に準拠したポリシーに沿って保管対象に対して保管期間を設定している

34. 34
年間バックアップ量の推移
0
0.5 (PB)
1.0 (PB)
2013 20192014 2015 2016 2017 2018
Logs DBs

35. 35
バックアップの全体像

36. 36
数年前までの構成
倉庫
NAS
サーバ群 RDBMS 分散 DB
テープ装置
Rakuten DCs

37. 37
現在、あるいは将来の構成(一部省略)
NAS
サーバ群 RDBMS 分散 DB
Rakuten DCs
Storage Gateway
東日本リージョン
ココについては後述

38. 38
Block Blobs に移行したデータ
1. セキュリティ要件の低いログ
重要な顧客情報などが入っていないログなど
2. 分散 DB のデータ
高セキュリティレベルのデータには利用していない

39. 39
どれくらい効果があったのか?

40. 40
巨大なテープ装置 1 個を完全破棄
10年以上に渡り継続稼働していた筐体の莫大な運用工数をゼロにできた

41. 41
ストレージ運用がゼロに
マネージドサービスである Azure Blob Storage の恩恵を受けることができた

42. 42
毎年倉庫に運ぶテープ総数が半分に
エンジニアリングとは程遠い作業を減らせた

43. 43
つまりどういうことかというと…
DC 1 拠点分を Azure に完全リプレース

44. 44
Ops の領域でも Dev 要素は必要だというお話
OSS 開発や Azure SDKs へのフィードバックなど
3rd SECTION

45. 45
1つ厄介な問題が…
分散 DB 環境のバックアップ

46. 46
現在、あるいは将来の構成(一部省略)
NAS
サーバ群 RDBMS 分散 DB
Rakuten DCs
Storage Gateway
東日本リージョン

47. 47
オンプレにある分散 DB の仕様
1. スケールアウト可能
複数の IA サーバで分散
2. MySQL 互換
ACID 特性を保証し、信頼できるトランザクション処理が可能
3. SFTP でバックアップ
mysql クライアントから専用の SQL 文を発行してバックアップが可能

48. 48
NAS
テープ装置
分散 DB
Rakuten DCs
NFS でマウント
FTP server1. FTP server を立てる
2. NAS をマウントする
3. NAS からテープに転送
今までの方法

49. 49
どうやって Azure にバックアップするか
NAS
1. NAS 2. File Storage 3. FTP を開発する

50. 50
FTP server with block
blobs を自分で開発する
結局、僕らが選んだ方法は…
https://goo.gl/H9gyJX

51. 51
Azure File Storage ではダメなのか?
1. ✗ NFS / ✓ SMB 3.0
FTP サーバは Linux 上で稼働させる予定だが SMB 3.0 に対する知見がない
2. コストが高い
月あたり ¥8.16/GB(LRS) である (Block Blobs = ¥1.64/GB)
3. 5TB / Volume
1 回のバックアップで 5TB を超えてしまうかも

52. 52
今までの方法 Azure 導入後
NAS
テープ装置
分散 DB 分散 DB
東日本リージョン
Block Blobs を NFS
でマウントすること
はできないRakuten DCs
NFS でマウント
FTP serverFTP server
Express Route

53. 53
利用している Azure のサービス
Virtual Machine Block Blobs ExpressRoute

54. 54
FTP server with block blobs の仕様

55. 55
RFC 959 で定義されたコマンド全てを実装
ただし、認証は Azure Storage の Access Key 形式にする

56. 56
FTP でファイルを受け取り Block Blobs に同期
Blob Storage は CAP 定理において同時に 3 つの保証が提供されている

57. 57
まず何からはじめたのか?

58. 58
GitHub で探す (ゼロから作るのではなく)
すでに同じことを考えているエンジニアがきっといるはず

59. 59
結果、作りかけのリポジトリを発見

60. 60
Golang 製
単一バイナリーにできるのでコレは使いやすそう
https://goo.gl/YIhARf

61. 61
FTP のコマンド全てはまだ実装されてない
FTP サーバとして使用するにはまだ未成熟な状態

62. 62
PR を送り FTP server として完成させる

63. 63
RFC 959 に加えて拡張コマンドも実装
ネストされた Block Blobs のパスに対応するため

64. 64
開発途中の、とあるエピソード

65. 65
サイズの大きい DB のバックアップが失敗する
DB のサイズは日を追うごとに増加していく

66. 66
最新の API 仕様に対応する必要があった
ブロックサイズが 4MB から 100MB に

67. 67
SDK の実装が API 仕様に追従できていなかった
ただ、その事実に当初僕らは気づいていなかった

68. 68
自力では解決できず…
1. サポートに報告
Block Blobs 側エラーを解析してもらう目的
2. 改修案をもらう
FTP server と SDK 両方を解析してくれた
https://goo.gl/YbjYvt

69. 69
その結果…
MS のエンジニアが SDK 側に Issue を発行
即座にマージ

70. 70
FTP server 開発から学んだこと

71. 71
サービスを使うだけでは使いこなせない
フィードバックしながら SDK の改修に協力する、など

72. 72
GIVE & TAKE が大事
利用者視点だけ持っているのでは
ダメである
https://goo.gl/Q1HGyB

73. 73
SDK が OSS で助かった
SDK がプロプライエタリであったら
ユーザにはどうすることもできない
https://goo.gl/7svoFZ

74. 74
Block Blobs
使いこなし Tips
FTP server 開発で学んだ…
https://goo.gl/OJVoxn

75. 75
Tips 1: 低コストを意識する

76. 76
思わぬ課金に要注意
容量課金以外にも API コール数なども課金対象
Bandwidth Outbound PricingBlob Storage Access Pricing

77. 77
専用線を活用する
インターネット通信料がかからない工夫をする

78. 78
分散 DB
東日本リージョン
Rakuten DCs
✗良くない例
インターネット通信料がかかる
FTP server

79. 79
分散 DB
東日本リージョン
Rakuten DCs
✓良い例
閉域インターネット網内は
コストはかからない
FTP server
Express Route

80. 80
Tips 2: SDK のご利用は計画的に

81. 81
Azure SDK for Go は未だに BETA リリース

82. 82
Storage SDK が分離 (GitHub より抜粋)
ココに注目

83. 83
と思ったら、また戻ってきた

84. 84
リポジトリ運用の方針が定まってない
Java、Python、Ruby、Node など他の言語は Storage SDK に分離している

85. 85
Storage SDK が Stable の言語はまだ少ない
どの言語も一部の API 仕様しか移行ができていない

86. 86
例えば、Ruby の SDK を確認すると…
まだ Preview リリース

87. 87
Tips 3: エラーハンドリングは確実に

88. 88
リクエスト成功率 90% 前後
Azure Portal より抜粋

89. 89
Go SDK 内部でも Retry 処理は実装されているが…
エラー処理やリトライ処理
を疎かにしない
ただし、これが実装されたのは4月末の出来事

90. 90
まとめ

91. 91
まずはストレージから
1. レガシー移行から検討してみる
テープバックアップなどのレガシーストレージ移行を検討してみるのが良い
2. コストメリットを活かす
思わぬ課金には注意する

92. 92
使いこなす = GIVE & TAKE
1. SDK のご利用は計画的に
バグがあればフィードバックをしよう
2. GIVE & TAKE
利用者視点ではダメ
https://goo.gl/Q1HGyB

93. 93
THANK YOU