楽天がモノリスー>マイクロサービスとオンプレー>クラウドで経験した光と闇
楽天がモノリスー>マイクロサービスとオンプレー>クラウドで経験した光と闇
- デブサミの話
概要
自己紹介
- R Aさん
- Mソフト Aさん
楽天で自分のサービス紹介
- 各サービスが横断的に使用するファンクションを開発運用
- サービスオペレーション改善グループに所属
- そのなかでDMCというサービスをしている
- 内容は、画像をためたり取得するのを引き受けるサービス
CurrentStructures and problems
過去のアーキテクトの話
- 11年継続中で新規に変更中
- Squid/VarnishというLayerのメンテナンス
- 10以上あるFunctionsのVersionUP
- アクセス負荷増加の増強
- MogileFSのDisk交換<ーオンプレのディクスで壊れやすいから交換がいる
変更後
- ExpressRouteでAzureから楽天のCDNへデータ転送
- Squid/VarnishをAzure上に構築していたが、課金されるのでCDNで受け付けるように変更
- Azureのキャッシュを外に提供するときに課金されるため
DatabaseIssue
AzureのMySQLの問題
- 一月に一回定期再起動をすることが発覚
- 楽天データセンターについてはスケジュール調整していたので問題なかった
- Azureに移行したことでこれが発生
- 一つのノード障害が発生時に冗長ノードへのフェールオーバが発生する
- アプリケーションはその間60秒間のDB接続停止を伴う
- 現在この仕組みは改善考えている(BYマイクロソフト)
- 前段にメッセージングの仕組みとかを入れる必要性があった
DataTransfer Issue
15億レコードの移行
- そのままネットワーク経由は難しい
- そこで、オフラインデータ移行するサービスー>AzureDataBoxを使った
- 小中大の3プランある
- ところが、Railsアプリケーションのアクティブストレージがネックになった
- RailsのAPIには、どこにデータを保管しているかというメタデータをもっており、それを更新する必要が発生した
- マイクロソフトで最近GAになった機能で、AzureStackEdgeをつかったからこれを改善できる
- オンプレからはNFSのストレージにみえるが、裏ではAzure上のストレージにあがっている
- 学んだ点:データトランスファーが発生するアプリに関してはネットワークオーバヘッドの工数を考慮する
Microservice from monolith
マイクロサービスにした理由
- それぞれのリクエスト量がちがったGETがはるかに多い
- テスト工数の削減
- トラブル時範囲を最小限
- 起動するときの速さー>コード量が少ない方がPODの起動が早い
- 開発の独立性
ISTIOを活用
- マイクロサービスが多くなるので、サービスメッシュ必須
- ISTIOをいれたHELM2を利用して
- 最近HELM3がでている
- availabilityゾーンで、KUBENET?があがらなかった
- AZUREのCLIを使うと、
- Kialiー>Network周りの確認ができる
- Jaeger,ElasticAPMで監視がらく
- PrometheusとGrahanaでK8sを管理
- AlertManger/Slackも活用
- IStio自体にもカナリアリリース機能はあるがFlaggerを使った方が楽
- カナリアリリースをしてくれるSupenakerはむずかしかった
- ブルーグリーンデプロイメントもしてくれる
- 最近マイクロソフトからサービスメッシュ向けのDaprというミドルウェアが出た。
- L7階層でなくもっと下の階層で制御できる
マルチリージョン
- 日本の西と東の2リージョン
- availabilityゾーンを使っている<-必ず使った方が良い
マイクロソフトのマルチリージョンによる負荷分散のサービス
- マルチリージョンの負荷分散
- リージョン内部の負荷分散
- レプリケーション
CI/CDPipeLIne
- CircleCI + Kaniko + Artifactory + GitHubEnterPrise
- Gitのタグを中心にPIPELINE作成
NextActions
今後挑戦したいもの
- DB:>Vitess->分散型MYSQLー>YOUTUBEで使われている
- Messaging-> Nats -> Kafkaより楽
- Obsevability->OpenTelemetryとイエーガー使うと、ネットワークトラフィックのトレースが簡単
- Chaos Engineering->ChaosToolkit -> ノードを落とすサービス
プレゼンする時のまとめ
プレゼンのポイント
#ストーリの進め方
課題
提案
効果
行動喚起
テーブルのDELETE文GAS
テーブルのDELETE文GAS作った
function deleteSQL() { // 現在のスプレッドシートの取得 var spreadsheet = SpreadsheetApp.getActiveSpreadsheet(); var objSheet = spreadsheet.getSheetByName("削除シート"); SpreadsheetApp.setActiveSheet(objSheet); var sheet = spreadsheet.getActiveSheet(); var topSql = "delete from "; var whereSql = " where institution_code = '"; var bottomSql = " ;" var tableCount = 5 var rowCount = 3 for(i=0; i < tableCount; i++) { for(j=0; j < rowCount; j++) { var range = sheet.getRange((i*rowCount) + (j + 1), 6); range.setValue(""); range.setValue(topSql + GetTableName(sheet, i + 6) + whereSql + GetCode(sheet, j + 6) + "' " + bottomSql); } } Browser.msgBox("作成完了"); } function GetTableName(sheet, row) { var result = GetCellValue(sheet, row, "1"); return result; } function GetCode(sheet, row) { var result = GetCellValue(sheet, row, "3"); return result; } function GetCodeCount(sheet) { var result = GetCellValue(sheet, "6", "4"); return result; } function GetTableCount(sheet) { var result = GetCellValue(sheet, "6", "2"); return result; } function GetCellValue(sheet, row, column) { var range = sheet.getRange(row, column) return range.getValue(); }
CloudSqlのためにローカルにDockerのCloudProxyたてる
CloudProxyのDockerをつくる
前提
MySQLのアンイストールがよい
- プロセスおとすより要らないものは消そう
- 5.7を付け忘れないこと。5.7以外のときはバージョン変える
brew uninstall mysql@5.7
MYSQLサーバプロセス確認方法
ps -axf | grep mysql
やること
Docker
- Docker-composeを用意
version: '3' services: db: image: "gcr.io/cloudsql-docker/gce-proxy:1.16" command: ["/cloud_sql_pr "-dir=/cloudsql", "-instances=XXXX=tcp:0.0.0.0:3306", "-credential_file=/config/xxxx.json"] volumes: - "/etc/ssl/:/etc/ssl/" - "/Users/xxxx/Desktop/xxxxjson:/config/xxxxx.json" ports: - "3306:3306"
進め方
1.サービスカウントのキーJSON発行 2.CloudSQLプロキシのDockerをおとす docker pull gcr.io/cloudsql-docker/gce-proxy:1.16 3.Docker-CompseYamlを作成↑ 4.docker-compose up -d
Webパフォーマンスガチ勢が本当に使っている技術
Webパフォーマンスガチ勢が本当に使っている技術
- PagespeedInsights100点を獲得する
- デブサミの話
概要
自己紹介
- プライムストラテジー中村けん牛さん
- クサナギというCENTOSベースのシステム開発
- KUSANAGISutakの開発
- 高速化だけでなく自動化もやっているサービス
論より証拠
デモンストレーション
- デブサミサイトを高速にします
- Onimaruを利用
- URLをみると見た目はデブサミだけど、違う
- 見た目は同じだけどAzure上にサイト再現している
- 本ちゃんのデブサミはChromeのDevToolでfinishまで20秒かかっていたが、高速化すると2秒になった
- 本番をPagespeedInsightにかけた
- 最適化したサイトもPagespeedInsightsにかけた
- 本番は14点で、最適化したほうは100点だった
内容ざっくりみた
- DesableCacheを使う。ブラウザキャッシュ使わない
- ソースコード比較して、変わっていることを確認
高速化の話
高速化背景
- Googleが早くしろってうるさい
- Googleはモバイルファーストインデックスとスピードアップデートをめざす
- Googleの広告収入があがるから早くしろって言ってくる
モバイルファーストと5G時代高速化
- バックエンドとレンダリングの高速化がより大きな差を生む時代
- 速度にとってコア数は関係ない。結局直列に処理されるから
高速化の目的
- UXの最大化、PV、CVR、回遊率、滞在時間の工場
Web高速化のしくみ
- ネットワーク、バックエンド、レンダリングを対象とする
レンダリング
- ファーストビュー、インタラクティブ、セカンドビューにわける
- PagespeedInsightの配点はファーストビュー、インタラクティブが7割
バックエンド高速化
構成
- WordPressを想定
- バックエンド高速化の基本はキャッシュ戦略が大事
- キャッシュ戦略は、CPUを動かさない、ネットワークストレージにアクセスしない、高速な処理系を採用
- キャッシュ利用の切り口として2つある
- キャッシュを使った時に最新のアウトプットを保証するもの(キャッシュする)ー>A
- 過去の情報を再利用するもの(キャッシュしない個人情報だから)ー>B
- 直せつアプリケーションを修正するものとしないものー>C
- NginXを使うならLUAを使えば早くなるー>D
インスタンスの速度改善
- CPUのコア数より周波数の高い処理系の方がスピードがでる(<-あたりまえ)
OS
- デゥクスキャッシュを活用する
- バッファキャッシュを活用する
nginx
- 使い所注意なのは、個人情報をキャッシュしないこと
- Open file cacheを設定ー>ファイルクローズをせずに、置いとくことでオーバヘッドを減らす
- Luaによるアプリケーションの高速化ー>Nginxの処理をフックできる
- Luaを使ったらNginxをサーバアプリフレームとして使える
- JITコンパイラの方が早いー>LUAJITおすすめ
- PCREもPCREJITを使った方が早い
- PHP5より7を使った方が2.5倍
- OPCacheを導入ー>コード変わればクリアされるから安心
- APCu->インメモリのキャッシュ
- PHPのPCREに関してもJITを使う方が良い
MySQL
- QueryCacheの導入
- 参照クエリの実行結果をメモリキャッシュ
- innodb_buffer_pool_sizeを絶対設定
- innodbはOSのディスクキャッシュを使わないので、バッファキャッシュサイズ設定したほうがよい
- 使われていないSQLクエリキャッシュ削除ー>やりかたはググる
WordPressの改善
- I/Oにももとづく最適化処理
- I/Oが同じならば、O/R Mapper使わずに、直接SQL実行して高速化
ネットワーク高速化(フロントエンド)
ネットワーク帯域の確保
- クライアントが5Gでもバックが100Mbpsだったりする
画像リソース
- 同一画像フォーマットの最適化
- JPEとPNGでも WebPを使う
- LazyLoadingをつかう
- Chromeのカバレッジをみて何パーセント使っているかみる
- テキストはgzip/blotliに圧縮
レンダリング高速化
- レンダリングプロセスは通常のサイトは全部一度に実行する
- ファーストビューに必要なリソースのみ最短で実行
- それによってインタラクティブになるまでの時間を快適にする(ユーザ操作を受け付け可能状態)
- 最後にセカンダリビューに実行する
JS/Webフォントの遅延
- 具体例はGoogleMAPはフッターにあるなら、フッターに行くまで描画する必要はないなど
高速化の自動化
以下ツールで自動化
- Gulpで画像圧縮自動化
- inotiywait -> https://qiita.com/hana_shin/items/9e03ad7a40b4fd7afb67