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

2023年8月24日に開催された、DBRE Summitでご紹介した資料です。
https://kinto-technologies.connpass.com/event/292402/

Transcript

1. OracleDBを用いたDBREの実現 〜 オイシックス・ラ・大地でやってみた〜 原智子（@tomomo1015 ) 2023/08/24
2. Agenda - はじめに - 会社概要 - 自己紹介 - コスト管理を始めた背景 - 余談：弊社の内情 - OracleDBを使うということ - 余談：OracleDBの運用でやっていること - まとめ
3. はじめに
4. ここまでに すごくすごい方々が いい話をしてくれたと思うので
5. 今日は事例集等でも 「あんまり聞かないな」と思う 内容で話します
6. 💰
7. そう、コスト！ お金の話がメインです
8. 会社概要
9. より多くの人が、よい食生活を楽しめるサービスを提供します よい食を作る人が、報われ、誇りを持てる仕組みを構築します 食べる人と作る人とを繋ぐ方法をつねに進化させ、 持続可能な社会を実現します 食に関する社会課題を、ビジネスの手法で解決します 私たちは、食のこれからをつくり、ひろげていきます
10. 主要事業 Oisix（オイシックス） 子 育てと仕 事の両 立に 忙しい共働き世代 主要な顧客層 30代〜40代 大地を守る会 健康的な食生活を送りたい ２人暮らしのシニア世帯 主要な顧客層 50代後半〜 らでぃっしゅぼーや 家 事も子 育てもこだわる 世帯 主要な顧客層 40代〜50代
11. 自己紹介
12. 自己紹介 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 —---------------------------------------------------------- まいえすきゅーえりたい　ぽすぐれない　おらくるってる
13. 自己紹介：余談 Q : X等などで「あかずきん」のアイコンが使われている理由は？ A：初めて登壇したコミュニティイベントが赤帽社さん主催のAnsibleのイベントで 　 赤い帽子で連想したキャラクターが「あかずきん」だったから。　　　　　　　　　 帽子の赤い色はずっと、Ansibleのロゴの色なんです。 ※成長しないこと※ 直前にしか 描かない （前回もイベント数時間前に 描いた、締切ギリギリの人）
14. コスト管理を始めた背景
15. SRE/DBREが実施する可視化の一部 システムの可視化 エラー等の障害 レイテンシ等の性能 ログ分析等からの 予兆検知 作業の可視化 リリース頻度 Toilの撲滅 運用の汎用化 障害訓練 コストの可視化 クラウド及び基盤の 利用コスト
16. SRE/DBREが実施する可視化 システムの可視化 エラー等の障害 レイテンシ等の性能 ログ分析等からの 予兆検知 作業の可視化 リリース頻度 Toilの撲滅 運用の汎用化 障害訓練 コストの可視化 クラウド及び基盤の 利用コスト 🧡人気🧡 なぜならカッコいいし SRE/DBRE感ある！ 🧡人気🧡 なぜならカッコいいし SRE/DBRE感ある！
17. SRE/DBREが実施する可視化 システムの可視化 エラー等の障害 レイテンシ等の性能 ログ分析等からの 予兆検知 作業の可視化 リリース頻度 Toilの撲滅 運用の汎用化 障害訓練 コストの可視化 クラウド及び基盤の 利用コスト 圧倒的 不人気 😂
18. コスト管理を始めた理由 技術全然わからないし（当社比） カッコいいダッシュボードもうあるし みんなあんまりやりたがらないから コスト管理やってみようかな？
19. コスト管理を始めた理由 - 請求書リストからシステムの実態と課題を把握できる - 前提として、システム構成図とか新規参画者に優しいドキュメントがないシステム向け - 利用製品等からシステムで何を使っているのか分かる - 例えばCircleCIがあると、アプリケーションのビルドこれでやっているか、等 - 抱えている課題も分かる - 例えばNewRelicとDataDogがあると、それぞれどう使い分けしているのか？実 は重複してる？等の課題を見つけられる - 事業部間で同じ製品の契約をしていると、実はまとめて契約したほうがお得？等
20. コスト管理を始めた理由 - 費用対効果を評価することで事業の利益率向上に貢献する - 費用対効果を測れるのは事業会社のエンジニアだけ - SLI/SLOが低いシステムに24/365サポートの契約があれば、契約内容を見直し て安価な契約やプロダクト選択の見直しを - 利用状況、実態を確認すると意外と使っていなかったりする - 「前使っていたけどもう使ってない」というものが残ったままになっていたり - SIerさんにお願いしっぱなしの場合は、まず自分たちで何に使っているかを　　 理解することから - 無駄なコストを減らす→利益率向上を通じて事業へ貢献する - 支出を減らして機能を維持or向上できれば、事業からするとシステムは良くなっ て支払いが減って、良い事しかない
21. コスト管理を大まかに分類 使っていない 機能重複している ↓ 契約見直し or 解除 使っている ↓ もう一つ深掘り してみる
22. コスト管理をやってみた結果 使っていない 機能重複している ↓ 契約見直し or 解除 使っている ↓ もう一つ深掘り してみる
23. コスト管理をやってみた結果 使っていない 機能重複している ↓ 契約見直し or 解除 使っている ↓ もう一つ深掘り してみる 事業にmustで必要なんだから いつも使っているものだから 本当に　見直すところ　ない？？
24. コスト管理をやってみた結果 弊社上司の素敵コスト削減結果🎉 AWSのNAT gatewayを整理して月額約$357のコストを削減しました
25. さて利用明細を見ると分かる
26. データベース 高い
27. DBは大抵一番インフラコストがかかる - DISK利用費用がまず高い - オンプレでもDBに使うストレージは大抵高価 - 安いストレージでDISK壊れまくるほうが大変なので、大抵いいの使ってる - クラウドでも性能いいものにするとものすごいお値段 - 拡張は簡単だけど、縮小はものすごく大変（基本できなくて移行するしかない） なので、不要データ削除等しないとただの金食い虫になる - ハイスペックCPU利用でサーバー代も高い - 昨今DISKの性能向上で、DISKよりCPUボトルネックになりがちで、　 より高価なサーバーを使う場面が多い - 特にクラウドだと、より高くなる - 処理できる量が増えると、メモリも欲しくなってしまう
28. もちろん それだけのコストをかけてまで システムにとって重要なのが データベース
29. だからといって あぐらをかいてはいけない
30. DBのコストダウンのためにできること - よくやっているアプローチ - 開発/試験環境のDBは、利用していない日は基本停止 - オンプレの場合はあまり効果がないor場合によってはよくないこともある - クラウドはDISK利用費用はかかりますが、インスタンス分等は安くなる - 開発者が簡単に起動停止できるような仕組みを作る - 一番コスト対効果があるアプローチを考える - CPUをよく使うなら、DB分割またはShardingを考える - 単純に分割する/Shardingするだけだと運用コストが増える可能性もあるので、 その場だけでなく事業の拡張計画や運用も考慮にいれたメリデメの検討を - DISK費用が高いなら、増えないようにする努力を - RDBMSであれば、そのデータが「リレーショナルな環境にあるべきなのか？」 を考えるor調査する - 結構ストレージだったりドキュメントDB、KVS系に出してもいいデータとかある - ハウスキープ機能、所謂「不要データを消す」ことをしているのか - 論理設計時点でのデータ量サイジングの見直しをしてみる
31. DBのコストダウンのためにできること - よくやっているアプローチ - サポート期間を考えた製品/バージョンの選択を - 当たり前ですが、構築してすぐバージョンアップは開発/運用コストが　　　　 上がるだけ - OSSのDBはどんどん新しいバージョンが出るので、どのバージョンが安定稼働　 するかなどを、コミュニティや実際触って「これがいい！」と宣言するのも　　 DBREの腕の見せ所
32. 余談：弊社の内情
33. オイシックス・ラ・大地の基盤利用状況 Amazon Web Service よく つかってます Microsoft Azure Windows いっぱいいます Google Cloud Platform BQつよい オンプレ いっぱいあるよ
34. オイシックス・ラ・大地のDB利用状況 DBエンジン名 インスタンス/台数割合 主な利用用途 備考 MySQL 50% マイクロサービス基盤 Auroraが多い Redis 15% アプリケーション処理の　 一次キャッシュ 最近引っ張り　 だこ PostgreSQL 10% データ分析 ソフトウェアのリポジトリ いつも無理 させてます Oracle database 20% マスタデータ/データ分析 事業における重要処理 弊社の神様 その１ IBM Db2 5% マスタデータ 事業における重要処理 弊社の神様 その２ ※他にMicrosoft SQL ServerやAmazon DynamoDBも使ってます
35. OracleDBを使うということ
36. まずOracleDBを 使ったことがない人が いらっしゃるかもしれないので おさらい
37. OracleDBとは - 概要 - 世界初の商用データベースです - Oracle社が開発しているデータベースエンジンです - DB-Engines情報ですと、世界で最も使われているDBエンジンです - 2023年8月24日時点の情報 - 1位 OracleDB、2位 MySQL、3位 Microsoft SQL Serverです - 利用シーン（個人の意見です） - 社会インフラ等、所謂「24/365無停止が当たり前」のシステムに利用 されている - 公共、金融、通信等の、「いつでも当たり前に使えるサービス」によく使われて います - 大抵が構成やユースケース等を社外に出し辛いところで使われているので、　　 コミュニティイベントやSNS等で事例紹介があまりされない＝あまり使われてい ないと思われがちですが、守秘義務等で情報発信できない場合もあると思います
38. OracleDBとは - メリット（個人の意見です） - 技術面 - 機能面において充実している - 他のDBエンジンでできることは、全てではないですが、大抵できる - 変なSQL投げてもIndex skip scanして効率よく処理したり、dumpする際にロッ クをかけなかったり、パラレルクエリで処理を高速化したりするので、開発者　 にとって開発し易い - RWノードがスケールする - OracleRACはRWノードがスケールする技術で、1コマンドでDBリソースが追加 できます(crlctl add resource） - この技術を2001年から実装し始め、DBの可用性において20年以上たった今でも 優位性がある - サポート面 - 契約をすると24h/365dayの手厚いサポートを受けられる - Bugに対し「そのDBに対しての」個別パッチを作ってくれる - 怪我をしたらすぐ「その人専用の」絆創膏やお薬を出してくれるイメージ - ミッションクリティカルなシステムにおいて非常に重要なポイント
39. 商用DBだからこそ 高機能/手厚いサポート ゆえの利用料金
40. ライセンス
41. 今回は私がよく使っている OracleDBを例に上げましたが 商用DBは他にも沢山あるので 他の有償DB使っている方は そのDBのことを考えながら 聞いてくださいね
42. さて OracleDBの技術者に問いたい
43. そのDBのライセンス 及び ライセンス形態
44. 理解していますか？ 把握していますか？？
45. どうゆうライセンスモデル？ 契約更新の頻度は？ 保守費用の内訳及び増額有無は？
46. もう一度：SRE/DBREが実施する可視化の一部 システムの可視化 エラー等の障害 レイテンシ等の性能 ログ分析等からの 予兆検知 作業の可視化 リリース頻度 Toilの撲滅 運用の汎用化 障害訓練 コストの可視化 クラウド及び基盤の 利用コスト
47. もう一度：SRE/DBREが実施する可視化の一部 システムの可視化 エラー等の障害 レイテンシ等の性能 ログ分析等からの 予兆検知 作業の可視化 リリース頻度 Toilの撲滅 運用の汎用化 障害訓練 コストの可視化 クラウド及び基盤の 利用コスト OracleDB等の商用DBを利用する上で ライセンス形態とその金額を知っておくことは DBREを体現する上で必須だと思ってます
48. OracleDBのライセンス - まずはライセンスの棚卸しを - 会社が契約している母数を把握する - その上で、それぞれのライセンスの妥当性を把握する - CPUライセンスなのか、NUPなのか - EEなのかSEなのか - EEの場合は追加で買っているライセンスについても確認する - 例えば「Lifecycle Management」を契約しているとして、実際構成の保存や 比較、PDBの作成とかしているのか確認してみる - それぞれがサービスのSLI/SLOに対して妥当なのか考える - ライセンスは公式マニュアルに記載がありますが、詳細はメーカーさんや契約 している代理店さんに聞いてみるのが一番わかりやすいです
49. OracleDBのライセンス - その上で… - 妥当なもの - 悲鳴あげるまで使い倒そう！ - 他のモダンなDBも触りたい…という方におすすめなのが、機能比較してみたり すると面白いですよ - OracleDBできるこれ、MySQLだとどんな動きするのかな？PostgreSQL　 にもこの機能あるかな？とか - 妥当じゃないもの - 不要なライセンスは契約解除する！ - 契約解除出来ない背景等もあるので、その場合は使い倒しましょう - 別DBエンジンへの移行計画もあり！ - SLI/SLO等が下がる場合は最初に経営層まで合意を取ること - 上がる場合も合意取りましょう - 商用DB→OSSのDBにすると基本的には下がるので、その合意は大事 - その場合は、単純なアプリケーションの改修コストだけでなく、その後の　　　 開発コスも考慮すること - PL/SQLいっぱい使ってるシステムがPL/SQL使えなくなることで開発コス トやリードタイムが上がることはよくある
50. 私が今の会社に入って学んだこと
51. 特に同じ事業会社の人に伝えたいのが その契約をしたのは　あなたの会社です 代理店さんやメーカーさんに 文句を言うのは 恥ずかしいと思うのでやめましょう
52. 過去のことなら何でも文句が言える ここが悪い　こんなことしてなければ でもそれはその当時 それが最善の策だったのかもしれない その時の背景は今はもうわからない
53. 経緯がどうあれ 「今」があることは ここに至るまでの 過去の人たちの最善の積み重ね だから私は過去の人達に 感謝をすることにしました
54. 今と　未来を どうすれば信頼性向上ができるのか 成長できるのか 楽しくできるのか それを考えることに　時間を使いましょう？
55. 余談：OracleDBの運用でやってること
56. 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でやってます
57. 高負荷SQLの出力
58. OracleDB運用で自動化していること 項目 概要 備考 DB起動停止 bot 開発DBのRDSの起動停止を Slack→AWS Chatbot経由で実行する RDSの起動停止権限を持たない人でも できる コンソールログイン不要 実行計画 自動取得 SlackにSQL文と実行スキーマを書く と、開発DB→本番DBで実行計画を　 取得してくれる 実行承認はDBREが実施 本番DBでの実行計画取得が気軽に行な え、SQL開発精度を上げました 運用特権権限 付与 緊急でデータ変更等を運用側で行う 歳、Slackで一言言うと権限を付与　 する DMLが全TABLEに対して実行可能 全操作監査ログ設定を入れています 毎日0時に全員REVOKEします
59. DB起動停止bot - DBの起動停止をAWS管理者/権限を持っていない人でも実施できる - こんな簡単な機能を作ってみるの一つの案 - うちの場合、RDSの特定のタグ＝yesじゃないと出来ないようにIAM側で制御かけ ています - コストもですが、毎度管理者が呼ばれて作業する手間、Toil削減にもなりました Slack AWS Chatbot Lamda RDS @AWS Lamda invoke Status Check stop/start AutoControl=yes
60. 実行計画自動取得 開発DBの実行計画 本番DBの実行計画
61. まとめ
62. コストの可視化をすると見えてくるもの コストの可視化 クラウド及び基盤の 利用コスト
63. コストの可視化をすると見えてくるもの コストの可視化 クラウド及び基盤の 利用コスト 会社の事業戦略に 見合ってる？ このコストって 妥当なの？ この製品達 機能重複してない？ これ使えるんだ！ 他でも使うところ 探そう！！
64. できるところから やっていき！！
65. ご清聴ありがとうございました！