MANABIYAで学んだことのよな落書き帳

blog

3月23日に 【国内最大級のエンジニア向け技術祭典】MANABIYA -teratail Developer Days-で聴講しました。
いずれも良いお話が聞けたと感謝しております。確かに学び舎でした。
「MANABIYAで学んだこと」を書きたくも、ほぼメモったことの書き起こしです。


2時間目 インフラ
分散処理とコンテナ化インフラの面白い関係

用いられたスライド：MANABIYA.tech にいってきた＆しゃべってきた - たごもりすメモ
このスライドが公開されることを事前にお聴きしており、それを見ただけでわかるようなことはメモしていません。発言を正確に反映したものではありませんし、ほんの一部です。

  • 本題の前の話
    • YAMLで書いたファイルはそのままでjarファイルのパス切り替えのデプロイだと、設定のみの変更がしにくい。それを再起動時に反映したいもののみDockerイメージにして、再起動で変更の反映ができる。
  • 本題
    • 今日の話は方向性や目指すべき点の話
  • モダンなシステムの共通点
    1. どのサーバーか意識せずにデプロイの頻度を高める
    2. プロセスを止めて変えて起動
    3. たとえば1プロセス30秒かかったら他で起動するとか特にクラウド事業者にとって都合の良い話
    4. ローカルファイルシステムを前提にせずネットワーク上の他のDBとかRESTで保存先を指定するのみとか
  • 分散処理の物語
    • ごく最近、OSS、CassandraとかHDFS、YARN,Mesos,k8sとか出てきた。
    • 分散技術は昔からあるが、広く使われていなかった。
    • 最初はストレージ -> 処理 -> リソースの順で実装され、どんどんコンテナ化され使われるようになった。
    • どこで何をするかを考えないといけなくなる。
    • できるソフトウエアは使われる。
  • モダンなシステムでのデータの配置
    • Dockerでできるのはプロセスの分離
    • k8sはデータは含まれず、ストレージの課題は解決していない。
    • クラウドならRDSとかS3とか使っているはず。
    • Logging は fluentdとかを想定
    • ストレージのライフタイムは数年、SLAも高くないと。
    • じゃぁ何かは、答えがない。わからないから、工夫のしがいがある。
    • コミュニティに体験をシェアしましょう !

3時間目 DB
AI系技術の一般化でデータベースに求められること

用いられたスライド：ＤＢ改造屋雑記: MANABIYA でお話する資料
スライドを読むのみで理解できるように作られています。私が印象に残った言葉のみ。

  • 説明としてAIとは違う言葉があるはず。AIは未来にしかないのだから。
  • 研究者とモデルとリソースはあるが、精度の高いデータが必要なのが今。データのあてがないと、収集コストでお金が尽きる。
  • 「ないことをする」に意味がある。

4時間目 DB
CrossSession

ステージ上の4名のみでなく、会場内でお話された内容を聞き取りながら、雑にメモした内容です。発言を正確に反映したものではありませんし、ほんの一部です。

  • 30年後のDB
    • ハードウエアの進化に追随するものが出てくるだろう。NVMや1000 Core対応、PG-Stromとか。
    • MySQLないですよね。Oracle Databaseがあれば良いんじゃないですか。
    • MongoDBとかRedisとかはスーパーグローバル変数があれば良かったのかなと。
    • RDBMSではないデータストアとか。
    • 30年前を想像すると、今あるのは、これからもあるんじゃないの。
    • データの型が違う ? DBがなくなる ?
    • RDBMSが残るのかというと、集合が主ではなくなるかも。
    • トランザクションを人間が書くのは難しいよね。
    • 住み分けはどうなっていくか。
    • 複数からの更新が入らないならスケールするようになっている。
    • KVSは得意な領域が限られる。
    • お金がどこに流れるかによって変わるのかも。
    • 細分化されるだろう。
    • 間のインターフェースがSQLなのが変わるかも ? SQLの次がないと変わらないんじゃ ? トランザクションのないデータストアにSQLかぶせるとか。
    • FDW ? PostgreSQLをHUBとして NoSQLと連携。トランザクションは、受け取ったところで管理するが FDWでは難しい。
    • NoSQLのトランザクション ? トランザクションがないから良いのに。
  • リファクタリング
    • DBは触りたくない。塩漬け。技術的負債になっているが。
    • バージョンアップ時のデータは、PostgreSQLは論理ダンプ取って入れ替えていく。
    • MySQLは再帰テストありき。
    • 10年ぐらい使おうと思ったらコード読んだ方が速いよ。
    • DBは政治が大事。現状に不満が無ければバージョン上げなくて良いんでは。
    • MySQL 5.5より前はサポートしたくない。塩漬けにも限度がある。
    • OSのバージョンをあげるのと同じタイミングとかで良いのでは ?
    • 一番寿命が短いのがハードウエア。
    • クラウドは事業者がソフトウエアのバージョンを上げる。
  • DBの選び方
    • この機能ないからダメ以外は、なんでもよいのでは ?
    • PostgreSQLだとParallel Queryとか FDWとか実装されてきているし。
    • MySQLの中で一番良さそうなのを選ぶ。InfiniDBとか。
    • 身近に助けてくれる人が多いものを選ぶのが良いかも。困った時に相談相手がいると、大怪我しにくい。
    • 良い点ばっかりだとアレなんで悪い話もちょっと。
      • MariaDB ColumnStore、InfiniDBだと、エラーメッセージの対応がキツイ。調べるとGitHubか自分のブログとか。
      • pgupgradeは良い評価を聴かない。PostgreSQLはバージョン違いのレプリケーションができない。PostgreSQLの拡張はメンテされなくなるときがあり、コミュニティがメンテしているものが良い。