Suche senden
Hochladen
MogileFSをバックエンドとしたPrivate S3の作り方
•
10 gefällt mir
•
15,052 views
Ryo Kuroda
Folgen
第3回ペパボテックカンファレンス
Weniger lesen
Mehr lesen
Ingenieurwesen
Melden
Teilen
Melden
Teilen
1 von 70
Jetzt herunterladen
Downloaden Sie, um offline zu lesen
Empfohlen
MogileFS をバックエンドとしたPrivate S3の作り方 【後半】API 編
MogileFS をバックエンドとしたPrivate S3の作り方 【後半】API 編
hiboma
Logicadの秒間16万リクエストをさばく広告入札システムにおける、gRPCの活用事例
Logicadの秒間16万リクエストをさばく広告入札システムにおける、gRPCの活用事例
Hironobu Isoda
ロードバランスへの長い道
ロードバランスへの長い道
Jun Kato
3GPP TS 38.300-100まとめ
3GPP TS 38.300-100まとめ
Tetsuya Hasegawa
MySQL5.7 GA の Multi-threaded slave
MySQL5.7 GA の Multi-threaded slave
Takanori Sejima
Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門
Etsuji Nakai
M08_あなたの知らない Azure インフラの世界 [Microsoft Japan Digital Days]
M08_あなたの知らない Azure インフラの世界 [Microsoft Japan Digital Days]
日本マイクロソフト株式会社
いまさら聞けないPostgreSQL運用管理
いまさら聞けないPostgreSQL運用管理
Uptime Technologies LLC (JP)
Empfohlen
MogileFS をバックエンドとしたPrivate S3の作り方 【後半】API 編
MogileFS をバックエンドとしたPrivate S3の作り方 【後半】API 編
hiboma
Logicadの秒間16万リクエストをさばく広告入札システムにおける、gRPCの活用事例
Logicadの秒間16万リクエストをさばく広告入札システムにおける、gRPCの活用事例
Hironobu Isoda
ロードバランスへの長い道
ロードバランスへの長い道
Jun Kato
3GPP TS 38.300-100まとめ
3GPP TS 38.300-100まとめ
Tetsuya Hasegawa
MySQL5.7 GA の Multi-threaded slave
MySQL5.7 GA の Multi-threaded slave
Takanori Sejima
Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門
Etsuji Nakai
M08_あなたの知らない Azure インフラの世界 [Microsoft Japan Digital Days]
M08_あなたの知らない Azure インフラの世界 [Microsoft Japan Digital Days]
日本マイクロソフト株式会社
いまさら聞けないPostgreSQL運用管理
いまさら聞けないPostgreSQL運用管理
Uptime Technologies LLC (JP)
監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性
監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性
Ohyama Masanori
オススメのJavaログ管理手法 ~コンテナ編~(Open Source Conference 2022 Online/Spring 発表資料)
オススメのJavaログ管理手法 ~コンテナ編~(Open Source Conference 2022 Online/Spring 発表資料)
NTT DATA Technology & Innovation
Keycloak拡張入門
Keycloak拡張入門
Hiroyuki Wada
とある診断員とAWS
とある診断員とAWS
zaki4649
さいきんの InnoDB Adaptive Flushing (仮)
さいきんの InnoDB Adaptive Flushing (仮)
Takanori Sejima
ゲームのインフラをAwsで実戦tips全て見せます
ゲームのインフラをAwsで実戦tips全て見せます
infinite_loop
TIME_WAITに関する話
TIME_WAITに関する話
Takanori Sejima
SQLチューニング入門 入門編
SQLチューニング入門 入門編
Miki Shimogai
IOS/IOS-XE 運用管理機能アップデート
IOS/IOS-XE 運用管理機能アップデート
シスコシステムズ合同会社
Amazon SNS+SQSによる Fanoutシナリオの話
Amazon SNS+SQSによる Fanoutシナリオの話
Yoichi Toyota
Golangにおける端末制御 リッチなターミナルUIの実現方法
Golangにおける端末制御 リッチなターミナルUIの実現方法
Masashi Shibata
さいきんのMySQLに関する取り組み(仮)
さいきんのMySQLに関する取り組み(仮)
Takanori Sejima
それでも環境依存は残っている~起きたり起きなかったりする問題のお話~
それでも環境依存は残っている~起きたり起きなかったりする問題のお話~
Hiroki Tateno
Vacuum徹底解説
Vacuum徹底解説
Masahiko Sawada
日本語テストメソッドについて
日本語テストメソッドについて
kumake
負荷テストを行う際に知っておきたいこと 初心者編
負荷テストを行う際に知っておきたいこと 初心者編
まべ☆てっく運営
MHA for MySQLとDeNAのオープンソースの話
MHA for MySQLとDeNAのオープンソースの話
Yoshinori Matsunobu
Microsoft License の基本
Microsoft License の基本
祥子 松山
フロー技術によるネットワーク管理
フロー技術によるネットワーク管理
Motonori Shindo
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
Amazon Web Services Japan
Azure Cloud Shell
Azure Cloud Shell
ryosuke matsumura
Azure How to Learn &ゆるふわ雑談Q&A
Azure How to Learn &ゆるふわ雑談Q&A
Keiji Kamebuchi
Weitere ähnliche Inhalte
Was ist angesagt?
監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性
監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性
Ohyama Masanori
オススメのJavaログ管理手法 ~コンテナ編~(Open Source Conference 2022 Online/Spring 発表資料)
オススメのJavaログ管理手法 ~コンテナ編~(Open Source Conference 2022 Online/Spring 発表資料)
NTT DATA Technology & Innovation
Keycloak拡張入門
Keycloak拡張入門
Hiroyuki Wada
とある診断員とAWS
とある診断員とAWS
zaki4649
さいきんの InnoDB Adaptive Flushing (仮)
さいきんの InnoDB Adaptive Flushing (仮)
Takanori Sejima
ゲームのインフラをAwsで実戦tips全て見せます
ゲームのインフラをAwsで実戦tips全て見せます
infinite_loop
TIME_WAITに関する話
TIME_WAITに関する話
Takanori Sejima
SQLチューニング入門 入門編
SQLチューニング入門 入門編
Miki Shimogai
IOS/IOS-XE 運用管理機能アップデート
IOS/IOS-XE 運用管理機能アップデート
シスコシステムズ合同会社
Amazon SNS+SQSによる Fanoutシナリオの話
Amazon SNS+SQSによる Fanoutシナリオの話
Yoichi Toyota
Golangにおける端末制御 リッチなターミナルUIの実現方法
Golangにおける端末制御 リッチなターミナルUIの実現方法
Masashi Shibata
さいきんのMySQLに関する取り組み(仮)
さいきんのMySQLに関する取り組み(仮)
Takanori Sejima
それでも環境依存は残っている~起きたり起きなかったりする問題のお話~
それでも環境依存は残っている~起きたり起きなかったりする問題のお話~
Hiroki Tateno
Vacuum徹底解説
Vacuum徹底解説
Masahiko Sawada
日本語テストメソッドについて
日本語テストメソッドについて
kumake
負荷テストを行う際に知っておきたいこと 初心者編
負荷テストを行う際に知っておきたいこと 初心者編
まべ☆てっく運営
MHA for MySQLとDeNAのオープンソースの話
MHA for MySQLとDeNAのオープンソースの話
Yoshinori Matsunobu
Microsoft License の基本
Microsoft License の基本
祥子 松山
フロー技術によるネットワーク管理
フロー技術によるネットワーク管理
Motonori Shindo
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
Amazon Web Services Japan
Was ist angesagt?
(20)
監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性
監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性
オススメのJavaログ管理手法 ~コンテナ編~(Open Source Conference 2022 Online/Spring 発表資料)
オススメのJavaログ管理手法 ~コンテナ編~(Open Source Conference 2022 Online/Spring 発表資料)
Keycloak拡張入門
Keycloak拡張入門
とある診断員とAWS
とある診断員とAWS
さいきんの InnoDB Adaptive Flushing (仮)
さいきんの InnoDB Adaptive Flushing (仮)
ゲームのインフラをAwsで実戦tips全て見せます
ゲームのインフラをAwsで実戦tips全て見せます
TIME_WAITに関する話
TIME_WAITに関する話
SQLチューニング入門 入門編
SQLチューニング入門 入門編
IOS/IOS-XE 運用管理機能アップデート
IOS/IOS-XE 運用管理機能アップデート
Amazon SNS+SQSによる Fanoutシナリオの話
Amazon SNS+SQSによる Fanoutシナリオの話
Golangにおける端末制御 リッチなターミナルUIの実現方法
Golangにおける端末制御 リッチなターミナルUIの実現方法
さいきんのMySQLに関する取り組み(仮)
さいきんのMySQLに関する取り組み(仮)
それでも環境依存は残っている~起きたり起きなかったりする問題のお話~
それでも環境依存は残っている~起きたり起きなかったりする問題のお話~
Vacuum徹底解説
Vacuum徹底解説
日本語テストメソッドについて
日本語テストメソッドについて
負荷テストを行う際に知っておきたいこと 初心者編
負荷テストを行う際に知っておきたいこと 初心者編
MHA for MySQLとDeNAのオープンソースの話
MHA for MySQLとDeNAのオープンソースの話
Microsoft License の基本
Microsoft License の基本
フロー技術によるネットワーク管理
フロー技術によるネットワーク管理
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
Ähnlich wie MogileFSをバックエンドとしたPrivate S3の作り方
Azure Cloud Shell
Azure Cloud Shell
ryosuke matsumura
Azure How to Learn &ゆるふわ雑談Q&A
Azure How to Learn &ゆるふわ雑談Q&A
Keiji Kamebuchi
JJUG CCC 20150411 grails3 Spring-boot
JJUG CCC 20150411 grails3 Spring-boot
Tsuyoshi Yamamoto
20150704 MS Azure最新 - innovation egg 第4回
20150704 MS Azure最新 - innovation egg 第4回
Keiji Kamebuchi
GCPUG Shimane #03 レポート
GCPUG Shimane #03 レポート
yoshioka_cb
Azure IaaS update (2018年6月~8月 発表版)
Azure IaaS update (2018年6月~8月 発表版)
Takamasa Maejima
Java 10でぼくたちの生活はどう変わるの?
Java 10でぼくたちの生活はどう変わるの?
Yuji Kubota
シスコ装置を使い倒す!組込み機能による可視化からセキュリティ強化
シスコ装置を使い倒す!組込み機能による可視化からセキュリティ強化
シスコシステムズ合同会社
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)
Noritaka Sekiyama
Micronaut on Azure 試してみた
Micronaut on Azure 試してみた
拓将 平林
いよいよマルチクラウドの時代!マルチクラウド検討比較する前に知っておくべきポイント(Oracle Cloudウェビナーシリーズ: 2020年9月9日) 株...
いよいよマルチクラウドの時代!マルチクラウド検討比較する前に知っておくべきポイント(Oracle Cloudウェビナーシリーズ: 2020年9月9日) 株...
オラクルエンジニア通信
知られざる。Alibaba Cloudを支えるテクノロジー (manabiya.tech)
知られざる。Alibaba Cloudを支えるテクノロジー (manabiya.tech)
Shinya Mori (@mosuke5)
GDLC11 oracle-ai
GDLC11 oracle-ai
Hirokuni Uchida
2018 07-23
2018 07-23
Yuji Oshima
20190220 AWS Black Belt Online Seminar Amazon S3 / Glacier
20190220 AWS Black Belt Online Seminar Amazon S3 / Glacier
Amazon Web Services Japan
Azure IaaS update (2018年6月~7月 発表版)
Azure IaaS update (2018年6月~7月 発表版)
Takamasa Maejima
Part 2: Data & AI 基盤 (製造リファレンス・アーキテクチャ勉強会)
Part 2: Data & AI 基盤 (製造リファレンス・アーキテクチャ勉強会)
Takeshi Fukuhara
Data Orchestration with LogicFlow
Data Orchestration with LogicFlow
Tomoyuki Obi
アプリのロギングからデータ収集・分析・活用
アプリのロギングからデータ収集・分析・活用
Atsushi Yokohama (BEACHSIDE)
Azure App Service Overview LT
Azure App Service Overview LT
Keiji Kamebuchi
Ähnlich wie MogileFSをバックエンドとしたPrivate S3の作り方
(20)
Azure Cloud Shell
Azure Cloud Shell
Azure How to Learn &ゆるふわ雑談Q&A
Azure How to Learn &ゆるふわ雑談Q&A
JJUG CCC 20150411 grails3 Spring-boot
JJUG CCC 20150411 grails3 Spring-boot
20150704 MS Azure最新 - innovation egg 第4回
20150704 MS Azure最新 - innovation egg 第4回
GCPUG Shimane #03 レポート
GCPUG Shimane #03 レポート
Azure IaaS update (2018年6月~8月 発表版)
Azure IaaS update (2018年6月~8月 発表版)
Java 10でぼくたちの生活はどう変わるの?
Java 10でぼくたちの生活はどう変わるの?
シスコ装置を使い倒す!組込み機能による可視化からセキュリティ強化
シスコ装置を使い倒す!組込み機能による可視化からセキュリティ強化
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)
Micronaut on Azure 試してみた
Micronaut on Azure 試してみた
いよいよマルチクラウドの時代!マルチクラウド検討比較する前に知っておくべきポイント(Oracle Cloudウェビナーシリーズ: 2020年9月9日) 株...
いよいよマルチクラウドの時代!マルチクラウド検討比較する前に知っておくべきポイント(Oracle Cloudウェビナーシリーズ: 2020年9月9日) 株...
知られざる。Alibaba Cloudを支えるテクノロジー (manabiya.tech)
知られざる。Alibaba Cloudを支えるテクノロジー (manabiya.tech)
GDLC11 oracle-ai
GDLC11 oracle-ai
2018 07-23
2018 07-23
20190220 AWS Black Belt Online Seminar Amazon S3 / Glacier
20190220 AWS Black Belt Online Seminar Amazon S3 / Glacier
Azure IaaS update (2018年6月~7月 発表版)
Azure IaaS update (2018年6月~7月 発表版)
Part 2: Data & AI 基盤 (製造リファレンス・アーキテクチャ勉強会)
Part 2: Data & AI 基盤 (製造リファレンス・アーキテクチャ勉強会)
Data Orchestration with LogicFlow
Data Orchestration with LogicFlow
アプリのロギングからデータ収集・分析・活用
アプリのロギングからデータ収集・分析・活用
Azure App Service Overview LT
Azure App Service Overview LT
MogileFSをバックエンドとしたPrivate S3の作り方
1.
GMO Pepabo, Inc. Ryo
kuroda @lamanotrama 2015/08/29 第3回ペパボテックカンファレンス MogileFS をバックエンドとした Private S3の作り方
2.
黒田 良 @lamanotrama >
技術基盤チーム > インフラ担当
3.
前半 (自分) • 全体アーキテクチャ •
インフラ 後半 (@hiboma) • APIアプリケーション
4.
前半アジェンダ > 何故Private S3? >
アーキテクチャ > 大規模MogileFSの運用 > Gatewayの仕組み > データインポート
5.
何故Private S3
6.
全社的にサービスインフラを オンプレミスから Private Cloud(Open Stack)に移行
7.
8.
課題
9.
静的コンテンツの保存、配信 > 主に画像 > 容量がそれなりに大きい >
各サービスがそれぞれ違った仕組みで独自に構築している > Nyah(IaaS)上に各サービスが再構築するのは非効率 > 可用性 > スケーラビリティ > 構築、運用コスト → 求められる大統一オブジェクトストレージサービス
10.
ペパボのオブジェクト ストレージと言えば
11.
30days Album
12.
30days Album > 2008年リリース >
大規模分散オブジェクトストレージ > perl製のMogileFSを使用 > 総容量: 750TB > 累計オブジェクト数: 22億
13.
高いデータ耐久性、稼働率 > 7年間でデータロストは一回(4個) > (不幸なレア条件が重なったため。鋭意シス テム改善中!) >
計画メンテを除いたサービスダウンは ほぼ無い > (以前は不安定な時期もありました)
14.
vs OpenStack Swift OpenStackにもオブジェクトストレージを提供するコンポー ネントはあるが… >
大規模分散オブジェクトストレージを安定運用するのは甘 くない > 30days AlbumのMogileFSは十分に安定している 最初からS3互換APIを備えているというメリットはあるが、 長い目でみるとそこの開発コストは十分相殺されると考えた。
15.
vs AWS S3 フルマネージドのS3でいいじゃん? >
容量や転送量のコスト面でオンプレの方が明ら かに優位 > 同程度の規模だと容量課金のみで数百万円/月 > 長年のノウハウ蓄積によってMogileFSの運用 コストはかなり下がった
16.
名称 ペパボストレージ
17.
名称 ペパボストレージ Bayt
18.
19.
アーキテクチャ
20.
30days
21.
30days + Bayt
22.
Bayt ① ②
23.
1. gateway > Nginx
+ ngx_mruby > インターネット、インターナルからリク エストを受ける > http(s)://<bucket_name>.hitmitsu.no.domain/ > http://bayt.30d.lan/<bucket_name>/ > apiにproxy > apiだけでは出来ないあれこれ(後ほど)
24.
2. api > Rails
+ Unicorn > mogilefsd、メタデータdbとのや りとり > 詳細は後半で
25.
この2つを作れば 基本的にはOK
26.
と、その前に 既存システムコンポーネントの 強化、安定化
27.
安定稼働しているとはいえ、全社的 に使うには心もとない部分もある
28.
メトリクスの充実化、可視化
29.
storageサーバの高集積化 自作サーバ期など、紆余曲折を経て 今は/dev/sdarまであるみっしり筐体がメイン
30.
DB(MySQL)サーバのリプレース > 2台→3台 (総入れ替え) >
MySQL5.1→MySQL5.5 > MHA導入 短時間のダウンタイムを許容できるなら2台 でもいけなくはない。 が、メンテナンス性がとにかく悪い。
31.
mogilefsdクラスタの強化 負荷が高くなるのは明白なのでスペッ クアップ&台数++
32.
問題発生
33.
mogilefsdがスケールしない mogilefsdはマスタープロセスからワーカ を生やすpreforkモデル _ mogilefsd _ mogilefsd
[monitor] _ mogilefsd [replicate] _ mogilefsd [replicate] _ mogilefsd [replicate] _ mogilefsd [replicate] _ mogilefsd [queryworker] _ mogilefsd [queryworker] _ mogilefsd [fsck] _ mogilefsd [fsck] _ mogilefsd [reaper] _ mogilefsd [delete] …
34.
mogilefsdがスケールしない 子が少ないうちは大丈夫
35.
mogilefsdがスケールしない 増やすと親が子からのメッセージに応答し なくなる(約700プロセスを境に) ❌ ❌ ❌
36.
mogilefsdがスケールしない スループットが大幅に低下。 困った。 ❌ ❌ ❌
37.
mogilefsdがスケールしない 親に気合をいれてみた。 renice -20 -p
親 ❌ ❌ ❌
38.
mogilefsdがスケールしない 元気でた。
39.
副作用 mogilefsdサーバがコンスタントに高負荷で 落ちる。 1. 稀に子の調子がわるくなり、親から殺される 2. 新しく生まれた子は-20の子なので-20 3.
過負荷で不安定になる 4. 更に子が死ぬ 5. -20っ子がモリモリ増える 6. もう無理
40.
過剰なやる気
41.
mogilefsd起動直後と、その後もこ まめにcronで親子のnice値の面倒を みることで解決。 (もうちょい綺麗になんとかしたい…)
42.
DB刺さる問題 1. MySQL5.5化以来、コンスタントにDBが刺さる (デッドロック) 2. 負荷がじりじり上がる 3.
MHAマネージャからのヘルスチェックがコケて、 自動でマスターフェイルオーバー 4. 復旧 入れててよかったMHA…とか言ってる場合ではない。
43.
雑に解決 > クエリの実行計画が変わったことで、元々使わ れていなかったindexが使われるようになった ことが原因 > mogilefs.file_to_replicate
nexttry > 要らんからdrop 色々調査、検証したけど長くなるので省略…
44.
既存の画像配信の品質向上 Bayt GWの仕組みと共通するため、まずは既存(30days)の画像配信周り (Nginx)の改善。 > Keep
Alive (client - nginx - unicorn) > Last-Modifiedヘッダ取り回しのバグ修正 > TLSオプティマイズ > upstream、reproxyのフォールバック設定見直し > storage(WebDAV)サーバのメモリバッファ上限引き上げ、worker数の調整 等などで、 30%程度高速化。レスポンスタイム、スループットの安定化。 @cubicdaiya さんの資料が大変参考になりました。 https://speakerdeck.com/cubicdaiya/nginxfalsepahuomansutiyuningu
45.
gateway
46.
(再度構成図)
47.
実URLへのreproxy処理 gw api storage
48.
実URLへのreproxy処理 GET http://mybucket.domain/a/b.jpg GET http://192.168.1.3/a/b.jpg Host:
mybucket.domain gw api storage
49.
実URLへのreproxy処理 X-Accel-Redirect: /reproxy X-Reproxy-URL: http://192.168.1.4/dev1/123.fid http://192.168.1.6/dev8/123.fid gw api storage
50.
実URLへのreproxy処理 gw api storage GET http://192.168.1.4/dev1/123.fid
51.
実URLへのreproxy処理 gw api storage ❌
52.
実URLへのreproxy処理 gw api storage GET http://192.168.1.6/dev8/123.fid
53.
実URLへのreproxy処理 gw api storage
54.
1. apiへproxy
55.
2. 内部リダイレクトとproxy
56.
3. 2つ目のURLへフォールバック
57.
ややこしいけど便利
58.
apiに届かなかった場合のエラードキュメント S3互換にしないとクライアントで困る。 bodyだけでなくstatus codeも。
59.
ngx_mruby の活用
60.
Serverヘッダ変更 Server: Bayt で帰ってくるとかっこいい。 (add_headerディレクティブでは変更できない)
61.
リクエストUUID(ぽいもの)の発行 Railsまで届かなかった場合でもclient、gw、apiでユ ニークなリクエストIDを共有する為にgwで発行。
62.
apiでHMAC認証をskipさせるヘッダを付与 特定の条件を満たすリクエスト > internalリクエスト > 認証未対応のクライアントからの特定バケットへのリクエスト (S3とは関係ないBayt独自仕様)
63.
ngx_mrubyのオーバーヘッド ほぼ無い(実質的に問題にならない) リクエストトータル で掛かった時間 (mrubyの処理が介 在しない)upstream へのリクエストのみ で掛かった時間
64.
太らない 活発な開発。劇的改善。@matsumotory ++ (スパイクはNginxと関係ないバッチ処理によるもの) ngx_mruby v1.12.14
65.
既存データの import
66.
S3互換なので > 既存のS3クライアント実装をそのままつ かえる > 某サービスの場合だと画像サーバ上のデー タpathをそのまま
s3cmd sync
67.
DBメンテ祭り import検証中に発覚した問題への対応。 > ETag(md5値)保存用のカラム追加 > インデックスの追加 >
path(object key)カラムのサイズを255→512に変更 > pathをcase sensitiveにする為にcollationを変更 約9億レコードのテーブルへのALTERで最長25時間。 MHAのオンラインマスター切り替えを利用したメンテナンスで 全てサービスダウンタイムは無し。
68.
粛々とインポート、移行 > 適当な単位でCDNからのOrigin指 定を切り替え > 3TB、1億オブジェクトを移行済 絶賛安定稼働中
69.
今後 > 全サービスのデータを移行 > マルチロケーション(DC)化 >
ディザスタリカバリ > サービスエンドポイントの冗長化 > 動的画像リサイズ機能 > URLパス、クエリパターンで動的にリサイズ、 配信
70.
以上。後半に続く。 API編 by @hiboma
Jetzt herunterladen