2024年 目標
目標一覧
- 育児に専念する
- 英語学習を続ける
- Database、コンテナの学習をする
- 個人開発を進める
1. 育児に専念する
1月中旬ごろ、子どもが生まれます！！！ ありがたいことに１年間近く育児休暇を取得できるので、最優先は育児に専念します。 育児に専念しつつも、まだまだ自分の力は足りないので できる範囲で勉強や個人開発も進めます。
2. 英語学習を続ける
2023年９月ごろから毎日継続して英語に触れられているので、来年も継続します。 最低限英語のハノンは続けます。 余裕があれば次もやりたい。 - WSJの購読 英語のハノンだけだとちょっと足りないのでは？と思い、海外の英語ニュースに触れる時間を増やしてみようかと考えています。 媒体はいろいろありますが、一旦有名なWSJかな～といった軽い感じです。 - 英会話 英語のハノンでインプット、英会話でアウトプットをしたい。 通常のオンライン英会話だと費用がかかるので、それは英語のハノンが終わってから検討。 ※英語のハノンは３シリーズあり、まだまだ終了は先。
3. Database、コンテナ、クラウドの学習をする
復職した後に参画するPJに備えた勉強です。 Databaseとコンテナについて、基礎的な部分は固めておきたい。 最終的な成果物は、K8s上でDatabaseを動かしたときの検証を記事にまとめること。 また、復職後はAWSも扱うのでAWS資格も取得する。
4. 個人開発を進める
今、撮影スタジオの予約フォームを作成しています。 予約フォームを作成/リリースできたら、今度は予約システムを自動化したい。 今は予約が来たら手動でカレンダーに登録している状況なので、これを自動化。 ただしセミオーダーチックな対応を顧客に対してしているので、そのあたりの運用は変えないようなシステムにしたい。
【読書メモ】AWSコンテナ設計・構築[本格]入門
はじめに
実務でAWSを触るようになりました。
これからコンテナを触っていくことも増えていくので次の本を読みました。
ハンズオンも実施できるので非常におすすめです。
注釈にある公式ドキュメントは、必ず参照したほうがいいと思います。
以下、読書メモにです。
ロギング設計
CloudWatch Logs or FireLens
CloudWatch Logs - 例）サブスクリプションフィルター：指定した文字列を含むログのみを抽出する - 抽出したログをlambdaに連携して障害を通知させる
メトリクス設計
- メトリクス：定量的な指標として定期的に計測/収集されるシステム内部動作のデータ
- CloudWatchメトリクスとCloudWatch Container Insightsに分けられる。 - CloudWatchメトリクス：CPU使用率、メモリ使用率( 1分間隔、ECSサービス単位 ) - CloudWatch：ECSタスクレベルで収取可能。ディスクやネットワーク情報も収集可能
Bastion設計
- 傷害調査等で各サーバへログインしたいとき、セキュリティ面や運用コスト面を考慮した設計が必要。
- セッションマネージャー経由の接続で、SSH接続が不要。IAM権限でログイン可能となるため、セキュリティ設定をIAMに集中管理できる。
コンテナイメージの脆弱性スキャン
- 継続的かつ自動的に実施することが重要。CI/CDに仕組みを取り入れる。 - CI/CDが実行されなければ、脆弱性スキャンが実施されないので、定期的な手動スキャンが必要。 - CloudWatch Eventsからlambdaを実行できる。
平文の秘密情報対策
- 秘密情報をSecrets ManagerやSSMパラメータストアに格納することで、環境変数として安全に提供できる。
- 具体的には各格納先のARNと環境変数名をタスク定義内でマッピングすることで、コンテナイメージ内のOS環境変数として認識させる。
信頼性設計
- マルチAZによる可用性向上 - FargateでECSサービスを稼働させると、ECSサービス内部がベストエフォートでAZ間の負荷バランスを調整しながらタスク配置する。
- 障害児切り離しと復旧 - CloudWatchを活用したECSタスクの障害検知 - RunningTaskCountとTaskCountメトリクスを組み合わせる。 - ECSサービスによるECSタスクの自動復旧 - ALBと連動したECSタスクの切り離しと自動復旧 - リタイア、リサイクル等によるECSタスク停止への対処 - リタイア：AWS内部のHW障害や脆弱性検知時、新しいECSタスクに置き換えるイベント - リサイクル：Fargate上で稼働しているECSタスクについて、パッチ適用や内部インフラストラクチャ更新のイベント
- システムメンテナンス時のサービス停止 - メンテナンス時、SorryページやSorryコンテンツを返却できることが理想。ALBのリスナールールの定義に設定できる。
ECR
SQLの練習PostgreSQL
備忘として、データセットの作成やPostgreSQLのコマンドをメモしておきます。
データセット作成
POSTGRESQL TUTORIALのサンプルデータセットを使用。
https://www.postgresqltutorial.com/postgresql-getting-started/postgresql-sample-database/
対話形式のシェルに移動
work用のPostgreSQLサーバを起動し、psqlで接続します。
dockerで用意しているので、コンテナ起動からです。
コンテナ起動
$ docker compose up -d
# -d はバックグラウンド実行
postgres接続
$ psql -h localhost -p 5432 -U postgres
# -h DBサーバのホスト指定
# -p DBサーバのポート番号指定
# -U DBサーバの接続ユーザ名指定
データセット用のデータベース作成
CREATE DATABASE dvdrental;
tarファイルを使った展開
pg_restore -h localhost -p 5432 -U postgres -d dvdrental ./dvdrental.tar
Databaseへ接続
psql -h localhost -p 5432 -d dvdrental -U postgres
TiDB User Day 2023に参加しました
はじめに
2023/07/07、TiDBUserDayというPingCAP社主催のパブリックイベントに参加してきました。私は2022、DB Techshowcaseに登壇したこともあり、TiDBについてはそれなりに理解した状態で臨みました。
TiFlashという分析系で使用するコンポーネントは使ったことがなかったので、分析系の事例紹介が多くて勉強になりました。と同時に、まだまだ勉強不足であることを痛感しました。NoSQLやその他製品との比較ができるまで深めて理解していきたいと思います。
さて、ここでは備忘も兼ねて事例紹介時にとったメモを起こしておきます。全8セッションでしたが、最初のセッションは英語であったことと、同時通訳してくださっていたトランシーバーが故障か何かで翻訳が聞こえなかったため、メモを取ったのは7セッションです。
こういう時のためにも英語は堪能になっておくべきだと感じたので、英語の勉強もちゃんとやります。
総評、個人の感想
・まだまだ勉強不足。低レイヤー層まで理解できる力をつける。NoSQLとRDBも。
・英語の勉強をちゃんとやる。目標は、CTOやCEOと英語で会話できるようになるレベル。
・TiDBを採用するメリットは、管理コストが削減できるところにあると感じている人が多い。
メンテナンスに向けた準備に取られる工数が削減できると感じている人が多い。
ただし、TiDBそのものの金額はあまり変わらないという意見もある。
・PingCAP社のサポートがかなりしっかりしていて信頼できる。
ドキュメントも充実、サポートも少数精鋭で優れている。
→私も同感。かなり手厚く支援してくれている印象。
・今回のセッションでは、TiDBCloudを使っている人がほとんどだったのでは。
→マネージドサービスではなく、ソフトウェアを使った事例も聞きたい。
各セッションの記録
TiDBによる大規模ログデータ管理の挑戦！シャーディングなしで大量インサートをさばくには？
- LINE株式会社 大塚 知亮 氏
社内クラウドでMySQLサービスを提供している。
サポートするインスタンスは6000以上！！
<運用上の課題>
・スケーラビリティ：ディスクサイズ3TB、CPU負荷、レプリケーション遅延
・シャーディングによる運用コスト増
⇒TiDBを活用することで解決できるのでは。
・社内のHA構成ツールのマルチリージョン対応
おっしゃる通り、TiUPをつかったデプロイは非常に簡単だった。
PDにもダッシュボードがあり、実行計画等、クエリの統計情報などを可視化できる
TiKV max-replicaは、TiKVのデータ管理単位を変更できるパラメータ。
設定値を5にすることで、多重障害への対策を取っていた。
補足：TiKV1インスタンスのRegion数が30000を超えるとCPUが跳ね上がるらしい
Regionは96MB単位なので、30000 * 96 = 2,880,000MBくらい
<疑問点>
PDリーダーの障害試験
クエリ停止時間は数秒だった→何秒だったのだろうか。
私が検証した時は約15秒ほどかかっていたので、当時よりは改善されていそう。
<後で調べること>
・TiDBOperator：K8s上で動かすコンポーネント
決済システムにおけるTiDB導入の検証とその効果
- SBペイメントサービス株式会社 - 前島 竜太郎 氏
私にもなじみのある決済サービス上での検証だった。
<検証した背景>
・メンテナンス時のダウンタイムによるサービス影響が顕著であった。
・クエリチューニングのためのアプリ開発者 - DBAとQAが増え、開発のリードタイムが増加していた。
JMeterつかった検証実施している！
<検証内容>
TiDBCloudとAuroraの比較（マネージドサービスの比較）
性能はAuroraの方が良かった。
思ったこと：
NewSQLが得意とするQPSがあるため、処理量が少なかったのかも、、、？
まあ、純粋にAuroraの性能の方が良かったのかもしれない。
さくらインターネットとヤマト運輸によるSlackアプリ
- さくらインターネット株式会社 江草 陽太 氏
伝わってきたこと：
将来の容量がわからなくてもスケールできるので、最小構成から開始できる！
LBではなくDNSによる負荷分散を実施しているとのこと。
<後で調べること>
DNSによる負荷分散する実装について
アジアNo.1のマーケティングSaaSを目指すMicoworksがNoSQLからNewSQLに移行した理由
- Micoworks株式会社 陳 瀚 氏
NoSQLからNewSQLへの移行をした。
思ったこと：
・分析で使える実システムがあるといいなあ。
TiDBの特徴の一つはHTAPであり、せっかくならこの特徴も使えるシステムがいい。
・実行計画を読み解く力は必要。
プロダクト分析サービスの超高速集計レイヤーとしてのTiDB
- 株式会社プレイド 小川 拓也 氏
データ分析基盤でのTiDB採用事例。
おなか一杯になってしまったので、メモはあまりとれておらず、、、
申し訳ありません。
金融業界のデータ処理ボトルネックを突破：技術革新の旅
- 株式会社SBI BITS 木内 祐介 氏
金融業界（証券）のデータ処理基盤で採用。
マーケットデータを蓄積し、意思決定/未来予測に活用している。
リアルタイム分析ができると、マネーロンダリング等犯罪の検知にも活用できる！
<運用上の課題>
ロックがかかってしまうため、リアルタイム分析はできず前日のデータを使っている状態。
要求があった場合過去データをテープなどから復元する必要がある。
TiDBの優れているところは、暗号化や監査ログのセキュリティ。
誤ってログを覗いてしまった、などを防ぐことができる。
resource controlを用いて複数環境を共存させることで、検証環境の準備コストを削減できた！
検証結果で思ったこと：
prometheusエラーにより停止した際、復旧に時間かかったとのこと。
つまり、監視が停止してしまっていることになる。
これは運用上問題となるので、実システムに採用する際は要検証する必要あり。
<後で調べること>
データ移行ツール：
TiDB Lightning https://docs.pingcap.com/ja/tidb/stable/tidb-lightning-overview
TiDB DM https://docs.pingcap.com/tidb/stable/dm-overview
TiCDC ⇒ データ同期ツールの位置づけ？
【パネルディスカッション】ゲーム業界のデータベースを覗いてみよう
- PingCAP株式会社 林 正記 氏
- 株式会社Cygames 宮脇 剛史 氏
- 株式会社スクウェア・エニックス 神津 和之 氏
- ワンダープラネット株式会社 中山 智義 氏
ゲーム業界のDBについて。
ゲーム業界の参加者は半分くらいだった。
ゲーム業界はMySQLが多く使われているらしい。
<登壇者 紹介>
ワンダープラネット 中山さん
TiDBの調査、導入を担当
スマホ向けゲーム/データベースの構造決定などを行っている
特性：ユーザデータが溜まり続けている / 数億~数十億レコード / 負荷分散を意識
月数回の新機能追加、そのタイミングでDBメンテナンス実施
→メンテナンスタイミングが限られているのが課題
スクエニ 神津さん
ソーシャルゲーム、アーケードタイプ
コロナ前くらいからパブリッククラウドへシフト
PaaSもIaaSも増えている。
サイゲームズ 宮脇さん
データベースを水平分割、垂直分割でDBいっぱい
300万QPS！！！
◆コストメリットをどう考える？
ワンプラ：
TiDB採用については、管理コスト削減という面でメリットを感じている。
ゲームイベントによってユーザ増減あり、分割数を調整する管理が軽減できそう。
機能開発の手を止めることがなくなる面でメリットを感じている。
シャード分割が増えるだけ性能が下がる点を解消したい、
分割方法を考えること、分割をミスするのを防ぐことができる点でメリット。
金額だけで言うと同じくらいで、管理コストを考えるとメリットあり。
特定シャードに負荷がかかるとかありそうだから、オーバースペック気味にサイジングしておく必要はある。
スクエニ：
TCOの観点で、PaaSと比較している。
ワンプラ同様、ゲームのメンテナンスにあわせてDBもメンテナンス。
シャードが増える→障害対策を考える場所が増えるということ。
⇒これを削減したい
分析計クエリにヒント句を追加して、全てTiFlashから参照するよう制限すれば、分析用のDB（余計なもの）を減らすことができる
サイゲームズ：
TiFlashにはあまり興味ない。笑
2社同様、金額的に安くなるとは考えていない。
如何にゲームを楽しんでくれるかを考えていて、やはりスケールアウトがカギになりそうと感じている。
エンジニア2，3人が数カ月拘束して、スケールアウトを考えている実態。
→これを解消することができれば嬉しい。
◆検証を通して分かったこと
ワンプラ：
TiDBへの期待：
・シャーディングなしでスケールが高い
・運用、学習コストが低い
シスベンチでwriteがスケールできるか確認。
→結果綺麗にスケールした。
TiDBCloudを用いることになると思う。
→DBに慣れていないエンジニアでもぽちぽちでできるため、学習コストは低そう。
互換性はありつつも、ストアド等のDB機能はあまりつかっていないのですんなり互換できた。
MySQLと同等性能なので、MySQLに戻すこともすんなりできる。
スクエニ：
MySQLとの互換性テストを実施。
互換性は問題なくつかえる。
ただしread-onlyで使っていたため、今後さらに検証は必要。
データの総量が圧縮されたが、どの程度圧縮されるのかとかは要検証。
→RocksDBの低レイヤ―層では圧縮がかかるようになる。
insertの検証は今後必要。
サイゲームズ：
性能試験→sysbenchをやっているケースが多い。
簡略化したシナリオを作って、Auroraと比較しようとした。
オートインクリメントを使うとスケールしない
インデックス使った検索がいまいち
→チューニングする必要がある。
Q：性能が出ていないとおっしゃったが、レイテンシーはどれくらいを目指している
→明確な基準はない。（都度クエリを最適化しようとしている）
→分析クエリ1秒未満を目指しているらしい。
◆アプリ開発側が気を付けた方がいいこと、MySQL互換について
ワンプラ：
アプリをそのまま持っていても動いた。
これまでのツールもそのまま使うことができた。
アプリ側で採番を行う設計に変更した。
→(個人の感想：アプリ側で採番することが当り前じゃないのか。)
DDLに時間がかかることがある。
→PingCAP社にサポートしてもらっているので、そんなに問題視はしていない。
スクエニ：
TiDBというよりMySQL全般の問題だが、オートインクリメントの数的な序列が維持できない。
最近は解決していると思うがレガシーシステムは考慮が必要。
サイゲームズ：
トランザクション開始時のスナップショット取得時間がいまいち。
(スナップショット取得時間に依存した処理をしているため。)
→リピータブルリードではなくリードコミットで十分と判断し、分離レベルを変更した。
◆今後のTiDBへの期待
ワンプラ：
融通の利くノードが増えると嬉しい。
でもフィーチャーリクエストは結構受け入れてくれている。
スクエニ：
同上
◆QA
Q：TiDBを知ったきっかけは？
ワンプラ
Spannerは知っていた。
CTOからTiDBの存在を聞かされ、調査を始めた。
スクエニ
Spannerの負荷試験を実施していた。
TiDBというよりも、NewSQLから入っていった。
サイゲームズ
上層部から教えてもらった。
Q：サブクエリを原則禁止している理由は？
水平分割してるので、同じテーブルに欲しいデータがないケースが多い。
またキャッシュに載ってるデータが多いので、キャッシュから取得した方が早い。
Q：パフォーマンスチューニングにて、TiDB側の設定変更はしたのか？
ワンプラ
まだそのフェーズではなさそう。
今後チューニングが必要な時期が来るので、そのタイミングで考えている。
スクエニ
まだパラメーターチューニングまでは進んでいない。
ブラックボックス化しているので安心している面がある。
モデレーター：多くのお客さんはパラメータチューニングはしていない。
サイゲームズ
基本的にはお任せしている。
今後チューニングが必要になる場合はある。
Q：クエリチューニングが必要になった時はどのように対応している？
基本的にはメトリクスや統計情報を確認している。
Q：TiDBCloudでサーバレスが追加されたが、サーバレスの検証は実施してる？あるいは視野に入れてる？
ワンプラ
コストがかからないので、開発環境で使おうかなと思っている。
本番環境では常に一定の負荷がかかっているので、おそらくこのまま。
スクエニ
開発環境で安く使えると思う。
本番環境でもできれば使いたい。
必要なディスクをサイジングして使っていたので、サイジングがなくなるといいと思う。
サイゲームズ
サーバレスは料金がわかりづらいので、あまり使おうとは思っていない。
Ｑ：Auroraだと、どのようなインパクトのある処理がある？
バージョンそのものをあげるものだと負荷が大きい。
2023/7目標 golangとSQLの基礎固め
目標設定の背景(先月の振り返り)
目標
2023年6月振り返り まだまだ努力が足りない
目標のおさらい
今月の目標はこんな感じだった。
- 日報の継続
- 予約管理システムのスプリント開始
- 「達人に学ぶDB設計指南書」の読了
- 「SQL実践入門」の進捗50%
- キャリアについて考える
進捗確認
達成できたこと
・日報の継続
学びのある日は言語化して振り返りもできていたので、このまま継続する。
習慣化はできたように思える。
・「達人に学ぶDB設計指南書」の読了
記事にもできた。
ある程度のDB設計知識は身に付けられたとは思うが、実践が圧倒的に足りていない。
予約管理システムを開発する際に経験を積むようにする。
・キャリアについて考える
DBを軸に成長していく。
7月以降、すぐ異動できるかを異動先の部長と交渉してみる。
希望は薄い気がする。
・技術雑誌の執筆
昨年、DB Techshowcaseに登壇した。(https://www.db-tech-showcase.com/2022/)
登壇内容を見てくださった編集部の方からお声がけいただき、記事を執筆できることになった。
また公開できるようになったら詳細を書こうと思う。
達成できなかったこと
・予約管理システムのスプリント開始
アジャイル開発の勉強、golangの勉強が完了していない。
アジャイル開発はいいかもだが、golangの基本は完成させたい。
・「SQL実践入門」の進捗50%
3章までしか読めていない。進捗20%ほどだろうか。
手を動かしながら確認したいので、PostgreSQLをローカル構築してから進めたい。
総評
60点/100点
まだまだ甘いところがあり、もっと勉強に費やせる時間があるはず。
悔いのない日々を過ごせるよう、理想に少しでも近づけるよう、毎日を大切に過ごす。
仕事についても、今以上に熱意をもって取り組まないと絶対に伸びない。
明日、7月の目標を共有する。
DB設計の基礎
はじめに
達人に学ぶDB設計徹底指南書 を読みました。
DB設計についてだけでなく、もう少し低レイヤの冗長化設計についても触れていて
基礎的な内容を整理できた本でした。
これからも何度も読み返して、完全に定着させます。
業務を通してできるなおよしですね。
一番伝えたいこと
あらゆるトレードオフの中から、均衡点を探し出すことがDBエンジニアの仕事である
・論理設計 <-> 物理設計
・データ整合性 <-> パフォーマンス
・データ量 <-> コスト
などなど
あらゆる方面に向けられたベクトルに対して、
ステークホルダーと調整しながら、システムに最適な均衡点を見つけることが
DBエンジニアのミッションなのだと感じました。
# DBエンジニアだけじゃなさそうだけど・・・
理解しておきたい基礎項目
以下は技術的な基礎項目のリストです。
どれも絵を描いて表現できるか(説明できるか)を基準に理解度のチェックします。
まとめず、項目と該当ページだけ記載します。
5章(論理設計とパフォーマンス)、6章(データベースとパフォーマンス)は再読必須。
・論理設計のステップ -> P.30
・物理設計のステップ -> P.34
・ストレージの冗長構成 -> P.41
・バックアップの種類 -> P.53
・バックアップ方式 -> P.59
・正規化 -> P.84
・関連エンティティ -> P.135
・正規化と非正規化のトレードオフ -> P.149
次に勉強すること
・個人開発システムにて、DB設計を行う。
・SQLについてもっと詳しくなりたいので、SQL実践入門を読む。
