OracleDBを用いたDBREの実現〜オイシックス・ラ・大地でやってみた〜

by tomo

Slide 1

Slide 1 text

OracleDBを用いたDBREの実現〜オイシックス・ラ・大地でやってみた〜原智子（@tomomo1015 ) 2023/08/24

Slide 2

Slide 2 text

Agenda - はじめに - 会社概要 - 自己紹介 - コスト管理を始めた背景 - 余談：弊社の内情 - OracleDBを使うということ - 余談：OracleDBの運用でやっていること - まとめ

Slide 3

Slide 3 text

はじめに

Slide 4

Slide 4 text

ここまでにすごくすごい方々がいい話をしてくれたと思うので

Slide 5

Slide 5 text

今日は事例集等でも「あんまり聞かないな」と思う内容で話します

Slide 6

Slide 6 text

💰

Slide 7

Slide 7 text

そう、コスト！お金の話がメインです

Slide 8

Slide 8 text

会社概要

Slide 9

Slide 9 text

より多くの人が、よい食生活を楽しめるサービスを提供しますよい食を作る人が、報われ、誇りを持てる仕組みを構築します食べる人と作る人とを繋ぐ方法をつねに進化させ、持続可能な社会を実現します食に関する社会課題を、ビジネスの手法で解決します私たちは、食のこれからをつくり、ひろげていきます

Slide 10

Slide 10 text

主要事業 Oisix（オイシックス）子育てと仕事の両立に忙しい共働き世代主要な顧客層 30代〜40代大地を守る会健康的な食生活を送りたい２人暮らしのシニア世帯主要な顧客層 50代後半〜らでぃっしゅぼーや家事も子育てもこだわる世帯主要な顧客層 40代〜50代

Slide 11

Slide 11 text

自己紹介

Slide 12

Slide 12 text

自己紹介 SQL> col name for a20 SQL> col department for a30 SQL> col history for a100 SQL> col other for a100 SQL> select name, department, history, other from oisixradaichi_dbre where name like ‘%tomo%’; NAME DEPARTMENT HISTORY —----------- —----------------- —--------------------------------------------------------------- 原智子(tomo) DBREセクション 12年SIerで通信系メインの開発PM＆DBA→ORDでSREからDBREへ OTHER —---------------------------------------------------------- まいえすきゅーえりたい　ぽすぐれない　おらくるってる

Slide 13

Slide 13 text

自己紹介：余談 Q : X等などで「あかずきん」のアイコンが使われている理由は？ A：初めて登壇したコミュニティイベントが赤帽社さん主催のAnsibleのイベントで　赤い帽子で連想したキャラクターが「あかずきん」だったから。　　　　　　　　　帽子の赤い色はずっと、Ansibleのロゴの色なんです。 ※成長しないこと※ 直前にしか描かない（前回もイベント数時間前に描いた、締切ギリギリの人）

Slide 14

Slide 14 text

コスト管理を始めた背景

Slide 15

Slide 15 text

SRE/DBREが実施する可視化の一部システムの可視化エラー等の障害レイテンシ等の性能ログ分析等からの予兆検知作業の可視化リリース頻度 Toilの撲滅運用の汎用化障害訓練コストの可視化クラウド及び基盤の利用コスト

Slide 16

Slide 16 text

SRE/DBREが実施する可視化システムの可視化エラー等の障害レイテンシ等の性能ログ分析等からの予兆検知作業の可視化リリース頻度 Toilの撲滅運用の汎用化障害訓練コストの可視化クラウド及び基盤の利用コスト 🧡人気🧡 なぜならカッコいいし SRE/DBRE感ある！ 🧡人気🧡 なぜならカッコいいし SRE/DBRE感ある！

Slide 17

Slide 17 text

SRE/DBREが実施する可視化システムの可視化エラー等の障害レイテンシ等の性能ログ分析等からの予兆検知作業の可視化リリース頻度 Toilの撲滅運用の汎用化障害訓練コストの可視化クラウド及び基盤の利用コスト圧倒的不人気 😂

Slide 18

Slide 18 text

コスト管理を始めた理由技術全然わからないし（当社比）カッコいいダッシュボードもうあるしみんなあんまりやりたがらないからコスト管理やってみようかな？

Slide 19

Slide 19 text

コスト管理を始めた理由 - 請求書リストからシステムの実態と課題を把握できる - 前提として、システム構成図とか新規参画者に優しいドキュメントがないシステム向け - 利用製品等からシステムで何を使っているのか分かる - 例えばCircleCIがあると、アプリケーションのビルドこれでやっているか、等 - 抱えている課題も分かる - 例えばNewRelicとDataDogがあると、それぞれどう使い分けしているのか？実は重複してる？等の課題を見つけられる - 事業部間で同じ製品の契約をしていると、実はまとめて契約したほうがお得？等

Slide 20

Slide 20 text

コスト管理を始めた理由 - 費用対効果を評価することで事業の利益率向上に貢献する - 費用対効果を測れるのは事業会社のエンジニアだけ - SLI/SLOが低いシステムに24/365サポートの契約があれば、契約内容を見直して安価な契約やプロダクト選択の見直しを - 利用状況、実態を確認すると意外と使っていなかったりする - 「前使っていたけどもう使ってない」というものが残ったままになっていたり - SIerさんにお願いしっぱなしの場合は、まず自分たちで何に使っているかを　　理解することから - 無駄なコストを減らす→利益率向上を通じて事業へ貢献する - 支出を減らして機能を維持or向上できれば、事業からするとシステムは良くなって支払いが減って、良い事しかない

Slide 21

Slide 21 text

コスト管理を大まかに分類使っていない機能重複している ↓ 契約見直し or 解除使っている ↓ もう一つ深掘りしてみる

Slide 22

Slide 22 text

コスト管理をやってみた結果使っていない機能重複している ↓ 契約見直し or 解除使っている ↓ もう一つ深掘りしてみる

Slide 23

Slide 23 text

コスト管理をやってみた結果使っていない機能重複している ↓ 契約見直し or 解除使っている ↓ もう一つ深掘りしてみる事業にmustで必要なんだからいつも使っているものだから本当に　見直すところ　ない？？

Slide 24

Slide 24 text

コスト管理をやってみた結果弊社上司の素敵コスト削減結果🎉 AWSのNAT gatewayを整理して月額約$357のコストを削減しました

Slide 25

Slide 25 text

さて利用明細を見ると分かる

Slide 26

Slide 26 text

データベース高い

Slide 27

Slide 27 text

DBは大抵一番インフラコストがかかる - DISK利用費用がまず高い - オンプレでもDBに使うストレージは大抵高価 - 安いストレージでDISK壊れまくるほうが大変なので、大抵いいの使ってる - クラウドでも性能いいものにするとものすごいお値段 - 拡張は簡単だけど、縮小はものすごく大変（基本できなくて移行するしかない）なので、不要データ削除等しないとただの金食い虫になる - ハイスペックCPU利用でサーバー代も高い - 昨今DISKの性能向上で、DISKよりCPUボトルネックになりがちで、　より高価なサーバーを使う場面が多い - 特にクラウドだと、より高くなる - 処理できる量が増えると、メモリも欲しくなってしまう

Slide 28

Slide 28 text

もちろんそれだけのコストをかけてまでシステムにとって重要なのがデータベース

Slide 29

Slide 29 text

だからといってあぐらをかいてはいけない

Slide 30

Slide 30 text

DBのコストダウンのためにできること - よくやっているアプローチ - 開発/試験環境のDBは、利用していない日は基本停止 - オンプレの場合はあまり効果がないor場合によってはよくないこともある - クラウドはDISK利用費用はかかりますが、インスタンス分等は安くなる - 開発者が簡単に起動停止できるような仕組みを作る - 一番コスト対効果があるアプローチを考える - CPUをよく使うなら、DB分割またはShardingを考える - 単純に分割する/Shardingするだけだと運用コストが増える可能性もあるので、その場だけでなく事業の拡張計画や運用も考慮にいれたメリデメの検討を - DISK費用が高いなら、増えないようにする努力を - RDBMSであれば、そのデータが「リレーショナルな環境にあるべきなのか？」を考えるor調査する - 結構ストレージだったりドキュメントDB、KVS系に出してもいいデータとかある - ハウスキープ機能、所謂「不要データを消す」ことをしているのか - 論理設計時点でのデータ量サイジングの見直しをしてみる

Slide 31

Slide 31 text

DBのコストダウンのためにできること - よくやっているアプローチ - サポート期間を考えた製品/バージョンの選択を - 当たり前ですが、構築してすぐバージョンアップは開発/運用コストが　　　　上がるだけ - OSSのDBはどんどん新しいバージョンが出るので、どのバージョンが安定稼働　するかなどを、コミュニティや実際触って「これがいい！」と宣言するのも　　 DBREの腕の見せ所

Slide 32

Slide 32 text

余談：弊社の内情

Slide 33

Slide 33 text

オイシックス・ラ・大地の基盤利用状況 Amazon Web Service よくつかってます Microsoft Azure Windows いっぱいいます Google Cloud Platform BQつよいオンプレいっぱいあるよ

Slide 34

Slide 34 text

オイシックス・ラ・大地のDB利用状況 DBエンジン名インスタンス/台数割合主な利用用途備考 MySQL 50% マイクロサービス基盤 Auroraが多い Redis 15% アプリケーション処理の　一次キャッシュ最近引っ張り　だこ PostgreSQL 10% データ分析ソフトウェアのリポジトリいつも無理させてます Oracle database 20% マスタデータ/データ分析事業における重要処理弊社の神様その１ IBM Db2 5% マスタデータ事業における重要処理弊社の神様その２ ※他にMicrosoft SQL ServerやAmazon DynamoDBも使ってます

Slide 35

Slide 35 text

OracleDBを使うということ

Slide 36

Slide 36 text

まずOracleDBを使ったことがない人がいらっしゃるかもしれないのでおさらい

Slide 37

Slide 37 text

OracleDBとは - 概要 - 世界初の商用データベースです - Oracle社が開発しているデータベースエンジンです - DB-Engines情報ですと、世界で最も使われているDBエンジンです - 2023年8月24日時点の情報 - 1位 OracleDB、2位 MySQL、3位 Microsoft SQL Serverです - 利用シーン（個人の意見です） - 社会インフラ等、所謂「24/365無停止が当たり前」のシステムに利用されている - 公共、金融、通信等の、「いつでも当たり前に使えるサービス」によく使われています - 大抵が構成やユースケース等を社外に出し辛いところで使われているので、　　コミュニティイベントやSNS等で事例紹介があまりされない＝あまり使われていないと思われがちですが、守秘義務等で情報発信できない場合もあると思います

Slide 38

Slide 38 text

OracleDBとは - メリット（個人の意見です） - 技術面 - 機能面において充実している - 他のDBエンジンでできることは、全てではないですが、大抵できる - 変なSQL投げてもIndex skip scanして効率よく処理したり、dumpする際にロックをかけなかったり、パラレルクエリで処理を高速化したりするので、開発者　にとって開発し易い - RWノードがスケールする - OracleRACはRWノードがスケールする技術で、1コマンドでDBリソースが追加できます(crlctl add resource） - この技術を2001年から実装し始め、DBの可用性において20年以上たった今でも優位性がある - サポート面 - 契約をすると24h/365dayの手厚いサポートを受けられる - Bugに対し「そのDBに対しての」個別パッチを作ってくれる - 怪我をしたらすぐ「その人専用の」絆創膏やお薬を出してくれるイメージ - ミッションクリティカルなシステムにおいて非常に重要なポイント

Slide 39

Slide 39 text

商用DBだからこそ高機能/手厚いサポートゆえの利用料金

Slide 40

Slide 40 text

ライセンス

Slide 41

Slide 41 text

今回は私がよく使っている OracleDBを例に上げましたが商用DBは他にも沢山あるので他の有償DB使っている方はそのDBのことを考えながら聞いてくださいね

Slide 42

Slide 42 text

さて OracleDBの技術者に問いたい

Slide 43

Slide 43 text

そのDBのライセンス及びライセンス形態

Slide 44

Slide 44 text

理解していますか？把握していますか？？

Slide 45

Slide 45 text

どうゆうライセンスモデル？契約更新の頻度は？保守費用の内訳及び増額有無は？

Slide 46

Slide 46 text

もう一度：SRE/DBREが実施する可視化の一部システムの可視化エラー等の障害レイテンシ等の性能ログ分析等からの予兆検知作業の可視化リリース頻度 Toilの撲滅運用の汎用化障害訓練コストの可視化クラウド及び基盤の利用コスト

Slide 47

Slide 47 text

もう一度：SRE/DBREが実施する可視化の一部システムの可視化エラー等の障害レイテンシ等の性能ログ分析等からの予兆検知作業の可視化リリース頻度 Toilの撲滅運用の汎用化障害訓練コストの可視化クラウド及び基盤の利用コスト OracleDB等の商用DBを利用する上でライセンス形態とその金額を知っておくことは DBREを体現する上で必須だと思ってます

Slide 48

Slide 48 text

OracleDBのライセンス - まずはライセンスの棚卸しを - 会社が契約している母数を把握する - その上で、それぞれのライセンスの妥当性を把握する - CPUライセンスなのか、NUPなのか - EEなのかSEなのか - EEの場合は追加で買っているライセンスについても確認する - 例えば「Lifecycle Management」を契約しているとして、実際構成の保存や比較、PDBの作成とかしているのか確認してみる - それぞれがサービスのSLI/SLOに対して妥当なのか考える - ライセンスは公式マニュアルに記載がありますが、詳細はメーカーさんや契約している代理店さんに聞いてみるのが一番わかりやすいです

Slide 49

Slide 49 text

OracleDBのライセンス - その上で… - 妥当なもの - 悲鳴あげるまで使い倒そう！ - 他のモダンなDBも触りたい…という方におすすめなのが、機能比較してみたりすると面白いですよ - OracleDBできるこれ、MySQLだとどんな動きするのかな？PostgreSQL　にもこの機能あるかな？とか - 妥当じゃないもの - 不要なライセンスは契約解除する！ - 契約解除出来ない背景等もあるので、その場合は使い倒しましょう - 別DBエンジンへの移行計画もあり！ - SLI/SLO等が下がる場合は最初に経営層まで合意を取ること - 上がる場合も合意取りましょう - 商用DB→OSSのDBにすると基本的には下がるので、その合意は大事 - その場合は、単純なアプリケーションの改修コストだけでなく、その後の　　　開発コスも考慮すること - PL/SQLいっぱい使ってるシステムがPL/SQL使えなくなることで開発コストやリードタイムが上がることはよくある

Slide 50

Slide 50 text

私が今の会社に入って学んだこと

Slide 51

Slide 51 text

特に同じ事業会社の人に伝えたいのがその契約をしたのは　あなたの会社です代理店さんやメーカーさんに文句を言うのは恥ずかしいと思うのでやめましょう

Slide 52

Slide 52 text

過去のことなら何でも文句が言えるここが悪い　こんなことしてなければでもそれはその当時それが最善の策だったのかもしれないその時の背景は今はもうわからない

Slide 53

Slide 53 text

経緯がどうあれ「今」があることはここに至るまでの過去の人たちの最善の積み重ねだから私は過去の人達に感謝をすることにしました

Slide 54

Slide 54 text

今と　未来をどうすれば信頼性向上ができるのか成長できるのか楽しくできるのかそれを考えることに　時間を使いましょう？

Slide 55

Slide 55 text

余談：OracleDBの運用でやってること

Slide 56

Slide 56 text

OracleDB運用で可視化していること項目概要備考高負荷SQL 最繁日のASHを分析して総所要時間等から高負荷なSQLをランキングしてレポートする内部処理でSQLiteを使ってます CSVファイルをインポートするとExcel でみやすくなってます Long Run SQL 1時間以上実行し続けているSQLを　検知するバッチ処理のSQL IDだけを除外して　ますタイムアウト SQL タイムアウトしたSQLがあった場合はSQL IDと実行元を通知する V$SQL_MONITORから取ってます MLOG監視 MVIEWのログが1GB以上になって　いるログを検知するそもそも溜まらないでお願い ORAエラーアプリケーションログを集計して ORAエラーの発生した場合通知する Datadogでやってます

Slide 57

Slide 57 text

高負荷SQLの出力

Slide 58

Slide 58 text

OracleDB運用で自動化していること項目概要備考 DB起動停止 bot 開発DBのRDSの起動停止を Slack→AWS Chatbot経由で実行する RDSの起動停止権限を持たない人でもできるコンソールログイン不要実行計画自動取得 SlackにSQL文と実行スキーマを書くと、開発DB→本番DBで実行計画を　取得してくれる実行承認はDBREが実施本番DBでの実行計画取得が気軽に行なえ、SQL開発精度を上げました運用特権権限付与緊急でデータ変更等を運用側で行う歳、Slackで一言言うと権限を付与　する DMLが全TABLEに対して実行可能全操作監査ログ設定を入れています毎日0時に全員REVOKEします

Slide 59

Slide 59 text

DB起動停止bot - DBの起動停止をAWS管理者/権限を持っていない人でも実施できる - こんな簡単な機能を作ってみるの一つの案 - うちの場合、RDSの特定のタグ＝yesじゃないと出来ないようにIAM側で制御かけています - コストもですが、毎度管理者が呼ばれて作業する手間、Toil削減にもなりました Slack AWS Chatbot Lamda RDS @AWS Lamda invoke Status Check stop/start AutoControl=yes

Slide 60

Slide 60 text

実行計画自動取得開発DBの実行計画本番DBの実行計画

Slide 61

Slide 61 text

まとめ

Slide 62

Slide 62 text

コストの可視化をすると見えてくるものコストの可視化クラウド及び基盤の利用コスト

Slide 63

Slide 63 text

コストの可視化をすると見えてくるものコストの可視化クラウド及び基盤の利用コスト会社の事業戦略に見合ってる？このコストって妥当なの？この製品達機能重複してない？これ使えるんだ！他でも使うところ探そう！！