O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
楽天のクラウドストレージ使いこなし術
Azure と OSS で少しずつ進めるレガシー脱却
Kentaro Sasaki
Cloud Infrastructure Engineer,
Global Operations Department,
...
2
Kentaro Sasaki
Biography:
Specialty:
分散ストレージ、OpenStack、etc.
インフラエンジニア @ Rakuten, Inc.
非常勤講師 @ NII
3
Tokyo-based e-commerce and Internet company
4
5
このセッションの
ゴール
実ユーザの体験談を知る
• 導入イメージを掴む
Azure, OSS, Give & Take and more.
• 使いこなすと何なのか
https://goo.gl/Lz6zEx
6
本日お話したい 3 つの内容
1. クラウド成功パターン (楽天のケース)
オンプレを利用してるユーザが上手くパブリッククラウドを使いこなすには?
2. バックアップの話
市場ローンチ時からあるレガシーシステムは如何にして僕らの眠りを妨げる...
7
クラウド導入における成功パターン
オンプレを利用してるユーザが上手くパブリッククラウドを使いこなすには?
1st SECTION
8
パブリック・プライベート両方知る立場から…
クラウド導入を成功させるために必要な要素とは?
On-premise Object Storage Public CloudPrivate Cloud
https://goo.gl/l9HnMF
9
短時間で効果を可視化出来る
スモールスタート
オンプレの方が安い場合もある
コストメリット
自前で用意するのは難しい
マネージド
3 IMPORTANT
KEYWORDS
01 02
03
10
これら 3 つの要素を踏まえた上で…
どのサービスから使い始めるのがよいのか?
11
クラウドストレージ
Block Blobs in Azure Storage
個人的なオススメはコレ
12
Block Blobs とは
一体何なのか?
写真のデータ、バックアップに最適
• オブジェクトストレージ
月あたり ¥1.64/GB (LRS-COOL)
• めちゃくちゃ安い
https://goo.gl/EfupHr
13
Block Blobs なら 3 つの要素を容易に満たせる
14
1. スモールスタート
15
システムにスモールに組み込める
小さく始めることができて辞めるのも簡単
16
2. コストメリット
17
短時間で実現可能で低コスト
GB 単価が安く、導入後すぐに成果を可視化することが出来る
18
3. マネージド
19
運用しなくてよい
ストレージの自社運用は総じて大変である
20
Block Blobs を活用できる使い方とは?
21
成功パターンの 1 例
テープバックアップからの脱却
小さく始めることが可能
https://goo.gl/wYJZXA
22
20 年間動いているテープバックアップのお話
市場ローンチ時からあるレガシーシステムは如何にして僕らの眠りを妨げるのか
2nd SECTION
23
https://goo.gl/cpzgeG
テープを減らす
レガシーからの脱却
24
テープ運用の大変なところ
25
倉庫の運用が大変
移送、リストア対応
https://goo.gl/gzsSMV
26
HW 障害が大変
ドライブがテープを巻き込んで壊れる
(半年に 1 回程度)
https://goo.gl/PCBeWR
27
テープ管理が大変
廃棄処理をする必要がある
(年 1 回、1000 本ほど)
https://goo.gl/gVZUHs
28
クラウド利用で良くなるところ
29
物理コンポーネントの排除
HW トラブルに対する対応時間を極小化できる
30
倉庫管理工数の削減
とはいえ、工数ゼロにはできない
31
DR (Disaster recovery) の実現
自社 DC 群と Azure のリージョンとの間で DR ができるようになる
自社 DC 群
東日本リージョン
32
楽天の場合…
33
保管対象とセキュリティー
1. 楽天(株)本体のデータ
楽天市場・会員ID / スーパーポイント などの共通基盤など
2. 楽天銀行、楽天Edy、楽天生命の一部データ
テープ保管倉庫内の保管区画も分離されている
3. セキュリティーポリシ...
34
年間バックアップ量の推移
0
0.5 (PB)
1.0 (PB)
2013 20192014 2015 2016 2017 2018
Logs DBs
35
バックアップの全体像
36
数年前までの構成
倉庫
NAS
サーバ群 RDBMS 分散 DB
テープ装置
Rakuten DCs
37
現在、あるいは将来の構成(一部省略)
NAS
サーバ群 RDBMS 分散 DB
Rakuten DCs
Storage Gateway
東日本リージョン
ココについては後述
38
Block Blobs に移行したデータ
1. セキュリティ要件の低いログ
重要な顧客情報などが入っていないログなど
2. 分散 DB のデータ
高セキュリティレベルのデータには利用していない
39
どれくらい効果があったのか?
40
巨大なテープ装置 1 個を完全破棄
10年以上に渡り継続稼働していた筐体の莫大な運用工数をゼロにできた
41
ストレージ運用がゼロに
マネージドサービスである Azure Blob Storage の恩恵を受けることができた
42
毎年倉庫に運ぶテープ総数が半分に
エンジニアリングとは程遠い作業を減らせた
43
つまりどういうことかというと…
DC 1 拠点分を Azure に完全リプレース
44
Ops の領域でも Dev 要素は必要だというお話
OSS 開発や Azure SDKs へのフィードバックなど
3rd SECTION
45
1つ厄介な問題が…
分散 DB 環境のバックアップ
46
現在、あるいは将来の構成(一部省略)
NAS
サーバ群 RDBMS 分散 DB
Rakuten DCs
Storage Gateway
東日本リージョン
47
オンプレにある分散 DB の仕様
1. スケールアウト可能
複数の IA サーバで分散
2. MySQL 互換
ACID 特性を保証し、信頼できるトランザクション処理が可能
3. SFTP でバックアップ
mysql クライアントから専用...
48
NAS
テープ装置
分散 DB
Rakuten DCs
NFS でマウント
FTP server1. FTP server を立てる
2. NAS をマウントする
3. NAS からテープに転送
今までの方法
49
どうやって Azure にバックアップするか
NAS
1. NAS 2. File Storage 3. FTP を開発する
50
FTP server with block
blobs を自分で開発する
結局、僕らが選んだ方法は…
https://goo.gl/H9gyJX
51
Azure File Storage ではダメなのか?
1. ✗ NFS / ✓ SMB 3.0
FTP サーバは Linux 上で稼働させる予定だが SMB 3.0 に対する知見がない
2. コストが高い
月あたり ¥8.16/GB(L...
52
今までの方法 Azure 導入後
NAS
テープ装置
分散 DB 分散 DB
東日本リージョン
Block Blobs を NFS
でマウントすること
はできないRakuten DCs
NFS でマウント
FTP serverFTP se...
53
利用している Azure のサービス
Virtual Machine Block Blobs ExpressRoute
54
FTP server with block blobs の仕様
55
RFC 959 で定義されたコマンド全てを実装
ただし、認証は Azure Storage の Access Key 形式にする
56
FTP でファイルを受け取り Block Blobs に同期
Blob Storage は CAP 定理において同時に 3 つの保証が提供されている
57
まず何からはじめたのか?
58
GitHub で探す (ゼロから作るのではなく)
すでに同じことを考えているエンジニアがきっといるはず
59
結果、作りかけのリポジトリを発見
60
Golang 製
単一バイナリーにできるのでコレは使いやすそう
https://goo.gl/YIhARf
61
FTP のコマンド全てはまだ実装されてない
FTP サーバとして使用するにはまだ未成熟な状態
62
PR を送り FTP server として完成させる
63
RFC 959 に加えて拡張コマンドも実装
ネストされた Block Blobs のパスに対応するため
64
開発途中の、とあるエピソード
65
サイズの大きい DB のバックアップが失敗する
DB のサイズは日を追うごとに増加していく
66
最新の API 仕様に対応する必要があった
ブロックサイズが 4MB から 100MB に
67
SDK の実装が API 仕様に追従できていなかった
ただ、その事実に当初僕らは気づいていなかった
68
自力では解決できず…
1. サポートに報告
Block Blobs 側エラーを解析してもらう目的
2. 改修案をもらう
FTP server と SDK 両方を解析してくれた
https://goo.gl/YbjYvt
69
その結果…
MS のエンジニアが SDK 側に Issue を発行
即座にマージ
70
FTP server 開発から学んだこと
71
サービスを使うだけでは使いこなせない
フィードバックしながら SDK の改修に協力する、など
72
GIVE & TAKE が大事
利用者視点だけ持っているのでは
ダメである
https://goo.gl/Q1HGyB
73
SDK が OSS で助かった
SDK がプロプライエタリであったら
ユーザにはどうすることもできない
https://goo.gl/7svoFZ
74
Block Blobs
使いこなし Tips
FTP server 開発で学んだ…
https://goo.gl/OJVoxn
75
Tips 1: 低コストを意識する
76
思わぬ課金に要注意
容量課金以外にも API コール数なども課金対象
Bandwidth Outbound PricingBlob Storage Access Pricing
77
専用線を活用する
インターネット通信料がかからない工夫をする
78
分散 DB
東日本リージョン
Rakuten DCs
✗良くない例
インターネット通信料がかかる
FTP server
79
分散 DB
東日本リージョン
Rakuten DCs
✓良い例
閉域インターネット網内は
コストはかからない
FTP server
Express Route
80
Tips 2: SDK のご利用は計画的に
81
Azure SDK for Go は未だに BETA リリース
82
Storage SDK が分離 (GitHub より抜粋)
ココに注目
83
と思ったら、また戻ってきた
84
リポジトリ運用の方針が定まってない
Java、Python、Ruby、Node など他の言語は Storage SDK に分離している
85
Storage SDK が Stable の言語はまだ少ない
どの言語も一部の API 仕様しか移行ができていない
86
例えば、Ruby の SDK を確認すると…
まだ Preview リリース
87
Tips 3: エラーハンドリングは確実に
88
リクエスト成功率 90% 前後
Azure Portal より抜粋
89
Go SDK 内部でも Retry 処理は実装されているが…
エラー処理やリトライ処理
を疎かにしない
ただし、これが実装されたのは4月末の出来事
90
まとめ
91
まずはストレージから
1. レガシー移行から検討してみる
テープバックアップなどのレガシーストレージ移行を検討してみるのが良い
2. コストメリットを活かす
思わぬ課金には注意する
92
使いこなす = GIVE & TAKE
1. SDK のご利用は計画的に
バグがあればフィードバックをしよう
2. GIVE & TAKE
利用者視点ではダメ
https://goo.gl/Q1HGyB
93
THANK YOU
Próximos SlideShares
Carregando em…5
×

[DO13] 楽天のクラウドストレージ使いこなし術 Azure と OSS で少しずつ進めるレガシー脱却

楽天市場ローンチ初期から 20 年続くレガシーなバックアップ環境が最新のストレージ技術により一新されようとしています。本セッションでは、楽天でのバックアップの全体像や、Azure のストレージ技術、関連する OSS がどのようにレガシーからの脱却に貢献しているのかについて、現場での運用に基づいた事例としてご紹介します。

受講対象: ツールやSDK、ライブラリのコードを読み書きし、積極的に運用を改善していく「新しい」Opsの生の声を聴きたいインフラ技術者、アーキテクトの方はぜひご参加ください。

製品/テクノロジ: DevOps/Linux/Microsoft Azure/OSS/アーキテクチャ/クラウド/運用

佐々木 健太郎
楽天株式会社
Global Operations Department
Cloud Infrastructure Engineer

  • Entre para ver os comentários

[DO13] 楽天のクラウドストレージ使いこなし術 Azure と OSS で少しずつ進めるレガシー脱却

  1. 1. 楽天のクラウドストレージ使いこなし術 Azure と OSS で少しずつ進めるレガシー脱却 Kentaro Sasaki Cloud Infrastructure Engineer, Global Operations Department, Rakuten, Inc.
  2. 2. 2 Kentaro Sasaki Biography: Specialty: 分散ストレージ、OpenStack、etc. インフラエンジニア @ Rakuten, Inc. 非常勤講師 @ NII
  3. 3. 3 Tokyo-based e-commerce and Internet company
  4. 4. 4
  5. 5. 5 このセッションの ゴール 実ユーザの体験談を知る • 導入イメージを掴む Azure, OSS, Give & Take and more. • 使いこなすと何なのか https://goo.gl/Lz6zEx
  6. 6. 6 本日お話したい 3 つの内容 1. クラウド成功パターン (楽天のケース) オンプレを利用してるユーザが上手くパブリッククラウドを使いこなすには? 2. バックアップの話 市場ローンチ時からあるレガシーシステムは如何にして僕らの眠りを妨げるのか 3. Dev, Ops and more. OSS 開発や Azure SDKs へのフィードバックなど
  7. 7. 7 クラウド導入における成功パターン オンプレを利用してるユーザが上手くパブリッククラウドを使いこなすには? 1st SECTION
  8. 8. 8 パブリック・プライベート両方知る立場から… クラウド導入を成功させるために必要な要素とは? On-premise Object Storage Public CloudPrivate Cloud https://goo.gl/l9HnMF
  9. 9. 9 短時間で効果を可視化出来る スモールスタート オンプレの方が安い場合もある コストメリット 自前で用意するのは難しい マネージド 3 IMPORTANT KEYWORDS 01 02 03
  10. 10. 10 これら 3 つの要素を踏まえた上で… どのサービスから使い始めるのがよいのか?
  11. 11. 11 クラウドストレージ Block Blobs in Azure Storage 個人的なオススメはコレ
  12. 12. 12 Block Blobs とは 一体何なのか? 写真のデータ、バックアップに最適 • オブジェクトストレージ 月あたり ¥1.64/GB (LRS-COOL) • めちゃくちゃ安い https://goo.gl/EfupHr
  13. 13. 13 Block Blobs なら 3 つの要素を容易に満たせる
  14. 14. 14 1. スモールスタート
  15. 15. 15 システムにスモールに組み込める 小さく始めることができて辞めるのも簡単
  16. 16. 16 2. コストメリット
  17. 17. 17 短時間で実現可能で低コスト GB 単価が安く、導入後すぐに成果を可視化することが出来る
  18. 18. 18 3. マネージド
  19. 19. 19 運用しなくてよい ストレージの自社運用は総じて大変である
  20. 20. 20 Block Blobs を活用できる使い方とは?
  21. 21. 21 成功パターンの 1 例 テープバックアップからの脱却 小さく始めることが可能 https://goo.gl/wYJZXA
  22. 22. 22 20 年間動いているテープバックアップのお話 市場ローンチ時からあるレガシーシステムは如何にして僕らの眠りを妨げるのか 2nd SECTION
  23. 23. 23 https://goo.gl/cpzgeG テープを減らす レガシーからの脱却
  24. 24. 24 テープ運用の大変なところ
  25. 25. 25 倉庫の運用が大変 移送、リストア対応 https://goo.gl/gzsSMV
  26. 26. 26 HW 障害が大変 ドライブがテープを巻き込んで壊れる (半年に 1 回程度) https://goo.gl/PCBeWR
  27. 27. 27 テープ管理が大変 廃棄処理をする必要がある (年 1 回、1000 本ほど) https://goo.gl/gVZUHs
  28. 28. 28 クラウド利用で良くなるところ
  29. 29. 29 物理コンポーネントの排除 HW トラブルに対する対応時間を極小化できる
  30. 30. 30 倉庫管理工数の削減 とはいえ、工数ゼロにはできない
  31. 31. 31 DR (Disaster recovery) の実現 自社 DC 群と Azure のリージョンとの間で DR ができるようになる 自社 DC 群 東日本リージョン
  32. 32. 32 楽天の場合…
  33. 33. 33 保管対象とセキュリティー 1. 楽天(株)本体のデータ 楽天市場・会員ID / スーパーポイント などの共通基盤など 2. 楽天銀行、楽天Edy、楽天生命の一部データ テープ保管倉庫内の保管区画も分離されている 3. セキュリティーポリシー 各種法令に準拠したポリシーに沿って保管対象に対して保管期間を設定している
  34. 34. 34 年間バックアップ量の推移 0 0.5 (PB) 1.0 (PB) 2013 20192014 2015 2016 2017 2018 Logs DBs
  35. 35. 35 バックアップの全体像
  36. 36. 36 数年前までの構成 倉庫 NAS サーバ群 RDBMS 分散 DB テープ装置 Rakuten DCs
  37. 37. 37 現在、あるいは将来の構成(一部省略) NAS サーバ群 RDBMS 分散 DB Rakuten DCs Storage Gateway 東日本リージョン ココについては後述
  38. 38. 38 Block Blobs に移行したデータ 1. セキュリティ要件の低いログ 重要な顧客情報などが入っていないログなど 2. 分散 DB のデータ 高セキュリティレベルのデータには利用していない
  39. 39. 39 どれくらい効果があったのか?
  40. 40. 40 巨大なテープ装置 1 個を完全破棄 10年以上に渡り継続稼働していた筐体の莫大な運用工数をゼロにできた
  41. 41. 41 ストレージ運用がゼロに マネージドサービスである Azure Blob Storage の恩恵を受けることができた
  42. 42. 42 毎年倉庫に運ぶテープ総数が半分に エンジニアリングとは程遠い作業を減らせた
  43. 43. 43 つまりどういうことかというと… DC 1 拠点分を Azure に完全リプレース
  44. 44. 44 Ops の領域でも Dev 要素は必要だというお話 OSS 開発や Azure SDKs へのフィードバックなど 3rd SECTION
  45. 45. 45 1つ厄介な問題が… 分散 DB 環境のバックアップ
  46. 46. 46 現在、あるいは将来の構成(一部省略) NAS サーバ群 RDBMS 分散 DB Rakuten DCs Storage Gateway 東日本リージョン
  47. 47. 47 オンプレにある分散 DB の仕様 1. スケールアウト可能 複数の IA サーバで分散 2. MySQL 互換 ACID 特性を保証し、信頼できるトランザクション処理が可能 3. SFTP でバックアップ mysql クライアントから専用の SQL 文を発行してバックアップが可能
  48. 48. 48 NAS テープ装置 分散 DB Rakuten DCs NFS でマウント FTP server1. FTP server を立てる 2. NAS をマウントする 3. NAS からテープに転送 今までの方法
  49. 49. 49 どうやって Azure にバックアップするか NAS 1. NAS 2. File Storage 3. FTP を開発する
  50. 50. 50 FTP server with block blobs を自分で開発する 結局、僕らが選んだ方法は… https://goo.gl/H9gyJX
  51. 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. 52 今までの方法 Azure 導入後 NAS テープ装置 分散 DB 分散 DB 東日本リージョン Block Blobs を NFS でマウントすること はできないRakuten DCs NFS でマウント FTP serverFTP server Express Route
  53. 53. 53 利用している Azure のサービス Virtual Machine Block Blobs ExpressRoute
  54. 54. 54 FTP server with block blobs の仕様
  55. 55. 55 RFC 959 で定義されたコマンド全てを実装 ただし、認証は Azure Storage の Access Key 形式にする
  56. 56. 56 FTP でファイルを受け取り Block Blobs に同期 Blob Storage は CAP 定理において同時に 3 つの保証が提供されている
  57. 57. 57 まず何からはじめたのか?
  58. 58. 58 GitHub で探す (ゼロから作るのではなく) すでに同じことを考えているエンジニアがきっといるはず
  59. 59. 59 結果、作りかけのリポジトリを発見
  60. 60. 60 Golang 製 単一バイナリーにできるのでコレは使いやすそう https://goo.gl/YIhARf
  61. 61. 61 FTP のコマンド全てはまだ実装されてない FTP サーバとして使用するにはまだ未成熟な状態
  62. 62. 62 PR を送り FTP server として完成させる
  63. 63. 63 RFC 959 に加えて拡張コマンドも実装 ネストされた Block Blobs のパスに対応するため
  64. 64. 64 開発途中の、とあるエピソード
  65. 65. 65 サイズの大きい DB のバックアップが失敗する DB のサイズは日を追うごとに増加していく
  66. 66. 66 最新の API 仕様に対応する必要があった ブロックサイズが 4MB から 100MB に
  67. 67. 67 SDK の実装が API 仕様に追従できていなかった ただ、その事実に当初僕らは気づいていなかった
  68. 68. 68 自力では解決できず… 1. サポートに報告 Block Blobs 側エラーを解析してもらう目的 2. 改修案をもらう FTP server と SDK 両方を解析してくれた https://goo.gl/YbjYvt
  69. 69. 69 その結果… MS のエンジニアが SDK 側に Issue を発行 即座にマージ
  70. 70. 70 FTP server 開発から学んだこと
  71. 71. 71 サービスを使うだけでは使いこなせない フィードバックしながら SDK の改修に協力する、など
  72. 72. 72 GIVE & TAKE が大事 利用者視点だけ持っているのでは ダメである https://goo.gl/Q1HGyB
  73. 73. 73 SDK が OSS で助かった SDK がプロプライエタリであったら ユーザにはどうすることもできない https://goo.gl/7svoFZ
  74. 74. 74 Block Blobs 使いこなし Tips FTP server 開発で学んだ… https://goo.gl/OJVoxn
  75. 75. 75 Tips 1: 低コストを意識する
  76. 76. 76 思わぬ課金に要注意 容量課金以外にも API コール数なども課金対象 Bandwidth Outbound PricingBlob Storage Access Pricing
  77. 77. 77 専用線を活用する インターネット通信料がかからない工夫をする
  78. 78. 78 分散 DB 東日本リージョン Rakuten DCs ✗良くない例 インターネット通信料がかかる FTP server
  79. 79. 79 分散 DB 東日本リージョン Rakuten DCs ✓良い例 閉域インターネット網内は コストはかからない FTP server Express Route
  80. 80. 80 Tips 2: SDK のご利用は計画的に
  81. 81. 81 Azure SDK for Go は未だに BETA リリース
  82. 82. 82 Storage SDK が分離 (GitHub より抜粋) ココに注目
  83. 83. 83 と思ったら、また戻ってきた
  84. 84. 84 リポジトリ運用の方針が定まってない Java、Python、Ruby、Node など他の言語は Storage SDK に分離している
  85. 85. 85 Storage SDK が Stable の言語はまだ少ない どの言語も一部の API 仕様しか移行ができていない
  86. 86. 86 例えば、Ruby の SDK を確認すると… まだ Preview リリース
  87. 87. 87 Tips 3: エラーハンドリングは確実に
  88. 88. 88 リクエスト成功率 90% 前後 Azure Portal より抜粋
  89. 89. 89 Go SDK 内部でも Retry 処理は実装されているが… エラー処理やリトライ処理 を疎かにしない ただし、これが実装されたのは4月末の出来事
  90. 90. 90 まとめ
  91. 91. 91 まずはストレージから 1. レガシー移行から検討してみる テープバックアップなどのレガシーストレージ移行を検討してみるのが良い 2. コストメリットを活かす 思わぬ課金には注意する
  92. 92. 92 使いこなす = GIVE & TAKE 1. SDK のご利用は計画的に バグがあればフィードバックをしよう 2. GIVE & TAKE 利用者視点ではダメ https://goo.gl/Q1HGyB
  93. 93. 93 THANK YOU

×