Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

データベーススペシャリストというキャリアと生存戦略 ~10年後も変わらないこと、変わること /...

soudai sone
September 22, 2023

データベーススペシャリストというキャリアと生存戦略 ~10年後も変わらないこと、変わること / career-spiral

soudai sone

September 22, 2023
Tweet

More Decks by soudai sone

Other Decks in Technology

Transcript

  1. 自己紹介
 曽根 壮大(38歳)
 Have Fun Tech LLC 代表社員
 株式会社リンケージ CTO


    
 そ
 • 日本PostgreSQLユーザ会 勉強会分科会 担当
 • 3人の子供がいます(長女、次女、長男)
 • 技術的にはWeb/LL言語/RDBMSが好きです
 • コミュニティが好き たけ
 ね
 とも

  2. • Amazon Web Service
 ◦ 東京リージョンのサービスインは 2011/03/02 
 ◦ Amazon

    Aurora MySQLがリリースされたのは 2014/10 
 ◦ Amazon DynamoDB がリリースされたのは 2012/3/1 
 • Microsoft Azure
 ◦ 東京リージョンのサービス開始は 2014/02/26 
 ◦ Azure Cosmos DBがリリースされたのは 2017年 
 • Google Cloud Platform
 ◦ 東京リージョンのサービス開始は 2016/11/8 
 ◦ Google Cloud Spannerの論文は2012年には発表されていたが、一般ユーザが利用でき るようになったのは2017年から
 クラウドの台頭
  3. • フルマネージドサービスによるDevOpsの実現
 ◦ RDBMSのフルマネージドサービスによるDBAの開放
 ◦ Redisなどの提供によるNoSQLの普及
 ◦ インフラの調達が容易になり、スケールアップ、シャーディングなどの 選択肢がより充実した
 •

    AWS S3のような高可用性でElasticにスケールするオブジェクトストレージ の出現
 ◦ logを簡単に、適切に、大量に保存できる
 ◦ 大規模なデータをクラウドに保存する時代の到来
 クラウドによるデータベースの変化 その1
  4. • 一定の規模までに対するインフラアーキテクチャのパターン化
 ◦ 本当の大規模・高負荷以外は対応できる
 ◦ クラウドベンダーの提供するホワイトペーパーを適切に活用すること が勘所になった
 • クラウドベンダー独自の技術によるNewSQLの到来
 ◦

    NewSQLもクラウドベンダーが提供する答えの一つ
 • ビジネスのコアにより注力できるよう変化
 ◦ ビジネスの実現する上でのインフラのボトルネックがほぼ皆無
 ◦ つまりよりソフトウェアの開発速度がビジネスの速度を決める
 クラウドによるデータベースの変化 その2
  5. • 常に追従が必要なバージョン
 ◦ 本来はあるべき姿がオンプレ時代は臭いものに蓋をしていた
 • データは基本的に追加なので増加していく
 ◦ サービスが成長すればするほどデータ容量は増える
 ◦ エラスティックにストレージは増強できるので容量は問題ない


    ◦ コストは?ビジネスの成長と比例している?
 ▪ 無料利用ユーザが増えてストレージを圧迫したり
 ▪ 無限にログを残してストレージを圧迫したり
 • クラウドで解決できないパターンの時はどうする?
 データベースと共に生きる
  6. • 常に追従が必要なバージョン
 ◦ 本来はあるべき姿がオンプレ時代は臭いものに蓋をしていた
 • データは基本的に追加なので増加していく
 ◦ サービスが成長すればするほどデータ容量は増える
 ◦ エラスティックにストレージは増強できるので容量は問題ない


    ◦ コストは?ビジネスの成長と比例している?
 ▪ 無料利用ユーザが増えてストレージを圧迫したり
 ▪ 無限にログを残してストレージを圧迫したり
 • クラウドで解決できないパターンの時はどうする?
 データベースと共に生きる • クラウドを活用して最適解を出すタイプ • クラウドで解けない問題を打開していくタイプ あなたはどちらを目指す?または両方?
  7. https://fortee.jp/phperkaigi-2023/proposal/98ad84b9-df03-4449-ab25-377761945005 Webサービスは生き物。機能追加によって常に成 長し、変化しています。
 そんな日々の中で、機能追加する際のデータベー スに対する変更はつきものです。しかし何気ない データベースの変更が障害の元になったり、機能 追加の障壁になっていたりしませんか? 
 
 •

    本番にALTERを流したらロックでサービスが死ん だ
 • 特定のカラムを毎回確認するifの列挙が辛い 
 • Viewで表示されるデータがSELECTしないとわか らない
 • 仕様追加の際にテーブル変更が怖い 
 
 そんな不安、心配を持っている皆様に明日からで きるテーブル設計についてお話します。 
 

  8. ここまでシンプルな実装を目指しましょうと強調してきました が、「シンプルな実装」とはなんでしょうか。RDBMSを使う上で シンプルな実装のヒントは正規化です。正規化のコツは次の ように表現できます。 
 • 事実だけを保存する 
 • 重複がない


    • 不整合がない
 • nullがない
 これらを意識して設計していくとシンプルな設計に近づいてい きます。
 また正規化を行う際はここまで説明したとおり、種別と状態を 考えることも重要です。ライフサイクルが違うデータは往々に して状態や種別が異なります。 場合によってはnullになるよう なカラムやUPDATEが必要なレコードは状態を持っている可 能性があります。こうしたテーブルが見つかった場合はより 深く考察する必要があります。 
 https://agilejourney.uzabase.com/entry/2022/07/28/103000
  9. 知る
 (知識の壁)
 やる
 (行動の壁)
 わかる
 (理解の壁)
 できる
 (技術の壁)
 している
 (習慣の壁)


    ステップアップしていくことが大切
 知らない
 (無知の知)
 越境とキャリアの螺旋
  10. もう少し私の職歴をご紹介すると、今回でCTO就任は3度目 となっており、Webアプリケーションエンジニア→最初の CTO→CRE→2度目のCTO→独立→3度目のCTOと、プレイ ヤーとマネージャーを交互に経験するようなキャリアを歩んで います。 CTOを通じたマネージャー経験は3回とも規模が違 いますが、「強くてニューゲーム」できるというメリットがあり、 回数を重ねるごとに違った経験と成長があります。 
 同じようにプレイヤーとマネージャーを行ったり来たりして、

    キャリアは一見、「振り子」のように見えますが、同じ場所に は戻っておらず、実は「螺旋」のようにつながっています。 ま たマネージャーやリーダーを経験した後のプレイヤーは視座 が高く、視野も広く、視点も鋭くなっていると感じています。 
 今回は私のちょっと変わった「 キャリアの螺旋」についてお話 しします。
 https://findy-code.io/engineer-lab/career-spiral