Amazon linux に PostgreSQL 9.3の環境を構築してみる

諸事情あって、EC2 on PostgreSQL 9.3 を知る必要があるので、ひとまず環境を作成してみる

やったこと

  • EC2環境構築
  • PostgreSQL 9.3 のインストール
  • PostgreSQL 9.3 の起動
  • ユーザとDB、tableを作成して、select を実行

EC2環境構築

適当に web UI から Amazon linux の t2.small を作成

  • ストレージはデフォルト8GBだと足りなそうなので16GBに

PostgreSQL 9.3 のインストール

手順

それぞれ、EC2環境にsshして実行している

  • yumリポジトリの設定ファイルの rpm をinstall
  • yum install

yumリポジトリの設定ファイルの rpm をinstall

PostgreSQL は yumリポジトリの設定ファイルをrpmで配布しているので、それを取得する

$ wget https://download.postgresql.org/pub/repos/yum/9.3/redhat/rhel-6-x86_64/pgdg-ami201503-93-9.3-3.noarch.rpm

rpmのインストール

$ sudo rpm -ivh pgdg-ami201503-93-9.3-3.noarch.rpm 

yumリポジトリが追加されたことを確認

$ rpm -ql pgdg-ami201503-93-9.3-3.noarch

/etc/pki/rpm-gpg
/etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG-93
/etc/yum.repos.d/pgdg-93-ami201503.repo

yum install

追加された postgresql93 関係のパッケージを確認

$ sudo yum list all  postgresql93*

読み込んだプラグイン:extras_suggestions, langpacks, priorities, update-motd
14 packages excluded due to repository priority protections
利用可能なパッケージ
postgresql93.x86_64                                                               9.3.25-1PGDG.rhel6                                                    pgdg93
postgresql93-contrib.x86_64                                                       9.3.25-1PGDG.rhel6                                                    pgdg93
postgresql93-debuginfo.x86_64                                                     9.3.25-1PGDG.rhel6                                                    pgdg93
postgresql93-devel.x86_64                                                         9.3.25-1PGDG.rhel6                                                    pgdg93
postgresql93-docs.x86_64                                                          9.3.25-1PGDG.rhel6                                                    pgdg93
postgresql93-libs.x86_64                                                          9.3.25-1PGDG.rhel6                                                    pgdg93
postgresql93-odbc.x86_64                                                          10.03.0000-1PGDG.rhel6                                                pgdg93
postgresql93-odbc-debuginfo.x86_64                                                09.03.0400-1PGDG.rhel6                                                pgdg93
postgresql93-plperl.x86_64                                                        9.3.25-1PGDG.rhel6                                                    pgdg93
postgresql93-plpython.x86_64                                                      9.3.25-1PGDG.rhel6                                                    pgdg93
postgresql93-pltcl.x86_64                                                         9.3.25-1PGDG.rhel6                                                    pgdg93
postgresql93-server.x86_64                                                        9.3.25-1PGDG.rhel6                                                    pgdg93
postgresql93-tcl.x86_64                                                           2.4.0-1.rhel6                                                         pgdg93
postgresql93-tcl-debuginfo.x86_64                                                 2.3.1-1.rhel6                                                         pgdg93
postgresql93-test.x86_64                                                          9.3.25-1PGDG.rhel6                                                    pgdg93

yum install postgresql-server すれば、必要なものはすべてインストールされるらしいので、それに従う

$ sudo yum -y install postgresql93-server.x86_64

結果、以下のパッケージがインストールされた

インストール中:
 postgresql93-server                         x86_64                         9.3.25-1PGDG.rhel6                           pgdg93                         4.1 M
依存性関連でのインストールをします:
 postgresql93                                x86_64                         9.3.25-1PGDG.rhel6                           pgdg93                         1.0 M
 postgresql93-libs                           x86_64                         9.3.25-1PGDG.rhel6                           pgdg93                         198 k

PostgreSQL 9.3の起動

PostgreSQLをインストールすると、postgresql userが追加されるので、それを確認

$ id postgres
uid=26(postgres) gid=26(postgres) groups=26(postgres)

serviceをONにする

$ sudo chkconfig postgresql-9.3 on
$ chkconfig --list postgresql-9.3

注記: この出力に含まれるのは SysV サービスのみです。ネイティブな 
      systemd サービスは含まれません。SysV の設定データはネイティブな
        systemd 設定で上書きされる場合があります。
      systemd サービスを一覧表示する場合は 'systemctl list-unit-files' を使用します。
      特定のターゲットで有効になっているサービスを確認する場合は
      'systemctl list-dependencies [target]'を使用します。

postgresql-9.3  0:off   1:off   2:on    3:on    4:on    5:on    6:off

initdb

$ sudo service postgresql-9.3 initdb -E UTF-8 --no-locale
  • -E はエンコードの指定。明示的に指定しないと、起動環境のエンコードを引き継ぐので、UTF-8を明示的に指定
  • --no-locale はロケールの指定。こちらも明示的にロケールを引き継がないようにしている(ソート順などに影響がでるらしい

起動

$ sudo service postgresql-9.3 start

本当はこの後にアクセス制限を設定する必要があるが割愛

ユーザとDB、tableを作成して、select を実行

ユーザの作成

$ sudo su - postgres
$ createuser ec2-user

DB作成権限を付与

$ psql
postgres=# ALTER ROLE "ec2-user" WITH CREATEDB;
ALTER ROLE

権限が付与されたことを確認

postgres=# \du
                             List of roles
 Role name |                   Attributes                   | Member of 
-----------+------------------------------------------------+-----------
 ec2-user  | Create DB                                      | {}
 postgres  | Superuser, Create role, Create DB, Replication | {}

DBの作成

ec2-user で実行

$ createdb mydb -U ec2-user

作られたことを確認

$ psql -l
                                         データベース一覧
   名前    |  所有者  | エンコーディング |  照合順序   | Ctype(変換演算子) |      アクセス権       
-----------+----------+------------------+-------------+-------------------+-----------------------
 mydb      | ec2-user | UTF8             | en_US.UTF-8 | en_US.UTF-8       | 
 postgres  | postgres | UTF8             | en_US.UTF-8 | en_US.UTF-8       | 
 template0 | postgres | UTF8             | en_US.UTF-8 | en_US.UTF-8       | =c/postgres          +
           |          |                  |             |                   | postgres=CTc/postgres
 template1 | postgres | UTF8             | en_US.UTF-8 | en_US.UTF-8       | =c/postgres          +
           |          |                  |             |                   | postgres=CTc/postgres
(4 行)

テーブルの作成

DBに接続

$ psql mydb

ここのチュートリアルを参考に、テーブルを作成してみる

CREATE TABLE weather (
    city            varchar(80),
    temp_lo         int,           -- 最低気温
    temp_hi         int,           -- 最高気温
    prcp            real,          -- 降水量
    date            date
);

作られたことを確認

mydb=> \d
            リレーションの一覧
 スキーマ |  名前   |    型    |  所有者  
----------+---------+----------+----------
 public   | weather | テーブル | ec2-user
(1 行)

行を挿入

INSERT INTO weather VALUES ('San Francisco', 46, 50, 0.25, '1994-11-27');

挿入されたことを確認

mydb=> select * from weather;
     city      | temp_lo | temp_hi | prcp |    date    
---------------+---------+---------+------+------------
 San Francisco |      46 |      50 | 0.25 | 1994-11-27
(1 行)

今日はここまで

その後やりたいこと

  • サンプルデータの挿入
  • レプリケーション
  • バックアップとリカバリ
  • DBのバージョンアップ(to 9.6)

WEB+DB PRESS Vol.108 詳解PostgreSQL 読書メモ

自分が知らなかったことや興味があったことだけをメモしているので、全体が知りたい人は WEB+DB PRESS を買って読みましょう

WEB+DB PRESS Vol.108

WEB+DB PRESS Vol.108

  • 作者: 中野暁人,山本浩平,大和田純,曽根壮大,ZOZOTOWNリプレースチーム,権守健嗣,茨木暢仁,松井菜穂子,新多真琴,laiso,豊田啓介,藤原俊一郎,牧大輔,向井咲人,大島一将,上川慶,末永恭正,久保田祐史,星北斗,池田拓司,竹馬光太郎,粕谷大輔,WEB+DB PRESS編集部
  • 出版社/メーカー: 技術評論社
  • 発売日: 2018/12/22
  • メディア: 単行本
  • この商品を含むブログを見る

バージョニングについて

9系までは、x.y.z の x.y がメジャーバージョン(9.6.5 ならば、9.6がメジャーバージョン)

  • ちなみに9系の最後のメジャーバージョンは9.6

10系からは、x.y の x がメジャーバージョン(10.1 ならば、10がメジャーバージョン)

2017年からは、2Q末にメジャーバージョンが毎年リリースされている

最新のメジャーバージョンはPostgreSQL11で、12が開発中

なお、各メジャーバージョンのサポート期限は4世代(4年)

初期設定いろいろ

ロケールのデフォルトは環境の言語に依存するので、依存しないように C にするのが一般的

文字コードはデフォルトは sql_ascii なので、UTF-8にしておくのが無難

パスワードと、IPアドレスによるアクセス制限をしっかりつけておく

PostgreSQLの内部構造

PostgreSQLはマルチプロセス(MySQLはマルチスレッド)

いろいろなプロセスが、それぞれの役割をこなしている

  • マスタプロセス : 最初に起動して、各プロセスを制御する
  • バックエンドプロセス : 接続要求毎に生成される
  • ライタ : 共有メモリの内容を定期的にストレージに書き込む
  • WALライタ : WAL(後述)をストレージに書き込む
  • チェックポインタ : ライタに書き込みのタイミングを通知する

など

PostgreSQLのデータ更新方法

基本的にはメモリ内(共有バッファ)上で、データを更新する

そして、ライタプロセスが、 チェックポイント と呼ばれる特定のタイミングで、メモリの内容をストレージに書き込む

  • これは、ストレージへの書き込みには時間がかかるので、高速化のため
  • なお、ストレージに書き込まれる前のデータを ダーティーページ という

それとは別に、WALライタが、共有バッファの更新毎に、差分をWALファイルに書き込んでいる

サーバがクラッシュした時には、 チェックポイントとメモリの差分はWALファイルに格納されているので、それを使ってリカバリを行う

メモリ

共有メモリプロセスメモリ の2種類がある

共有メモリ

PostgreSQL全体で使用するメモリ

  • 共有バッファ : テーブルやインデックスのデータをキャッシュする領域。 総メモリの25%程度が適切な値
  • 可視性マップ空き領域マップ : VACUUM処理(後述)が使用
  • WALバッファ : 上述のWALをキャッシュする領域

プロセスメモリ

バックエンドプロセス毎に持つメモリ

  • 作業メモリ : クエリ実行時に使用するメモリ。
    • 実行されるクエリのデータサイズが大きければ必要量が増える
    • ここが減るとswapが発生するので、 swapを監視すると良い
    • (OSのメモリ - 共有バッファのサイズ)/max_connection を超えない範囲でチューニングしていく必要がある
    • 最初は 32MB 程度にして、様子を見ていくのが良い
  • 一時バッファ : 一時テーブル作成時に使用
  • メンテナンス用作業メモリ : VACUUM(後述)、インデックス作成、外部キー制約の追加などのメンテナンス用の作業メモリ
    • 小さいとメンテナンス作業時にswapが発生して処理が遅くなる

ファイル

  • データファイル : テーブルのデータ。8192バイト毎の複数のファイルの格納されている
  • インデックスファイル : インデックスのデータ。同じく、8192バイト毎の複数のファイル
  • WALファイル : 16MB固定
  • TOASTファイル : 8192バイトを超えるデータの格納先、ただし最大1GBまで
    • そのため、PostgreSQLのTEXT型が持てる最大サイズも1GBまで

追記型アーキテクチャとVACUUM

PostgreSQLのデータの更新は、参照を置き換えるという形

  • 遅いが、トランザクションやロックの制御がシンプルになるというメリットがあるらしい

参照を置き換えた結果、使用されなくなったデータファイルは VACUUM という仕組みを使って再利用される

  • 共有メモリの 可視性マップ にデータファイルの参照状態が格納されているので、VACUUMはそれを参照する

なお、PostgreSQLでは データを削除してもデータファイルの合計サイズは減らない

  • VACUUMは、使用されなくなったデータファイルを再利用可能にするだけ
  • データファイルの総量を減らしたい場合は CLUSTER コマンドが適切らしい
  • また、 pg_repack というツールもある

他のVACUUMの機能

  • 統計情報の更新
  • トランザクションID(XID)の再利用
    • PostgreSQLは、テーブルやレコード全てにXIDを割り当てている
    • XIDを使い切る前に、未使用のXIDを再利用可能にしている

バックアップ

  • pg_dump
    • スタンダードな論理バックアップ
    • カスタムアーカイブ形式がオススメ(テーブルやスキーマ定義だけ分離できる&いざとなったらSQLに戻せる)
  • pg_basebackup
    • DBを停止せずにバックアップを取る方法
    • データファイルのコピーをしながら、コピーしている間に発生したWALもアーカイブする(WALアーカイブモードを有効にする必要あり
    • pg_rman は、上記のバックアップ&リストアを簡単に行えるツール

レプリケーション

ストリーミングレプリケーションと、ロジカルレプリケーションがある

ストリーミングレプリケーション

  • 主流。スタンバイが、プライマリのWALの更新を受け取って自身のDBを更新する
  • プライマリとスタンバイのマイナーバージョンが異なっても、レプリケーションができる

ロジカルレプリケーション

  • PostgreSQL10から追加
  • 自由度が高い
    • メジャーバージョンが異なってもレプリケーションができる
    • 複数のプライマリを集約したりとかもできる
  • その分壊れやすい
  • AWS DMSっぽい印象

バージョンアップについて

マイナーバージョンアップ

積極的に対応するべき

PostgreSQLの再起動が必要だが、ストリーミングレプリケーションを使って、スタンバイから更新すれば難しいことはないはず

メジャーバージョンアップ

ストリーミングレプリケーションは使えない

データファイルやWALに互換性がないこともあるため、物理バックアップからの復旧もできない

pg_dump の結果を新バージョンのDBに反映させるのが一番スタンダード

  • デメリット: 停止時間が長い。サーバを新規に用意する必要がある
  • メリット: 元のサーバが残っているため復旧が容易

現在のサーバで pg_upgrade するほうが、停止時間は短い

  • PostgreSQL 8.4 移行はデータファイルのフォーマットが変わっていないので、テーブルやインデックスの再構築が行われない
  • デメリットは、バージョンダウンはできない
  • EC2を使っている場合、スナップショットから復旧すれば良いので、デメリットは無視できそう

参考書籍

これからはじめる PostgreSQL入門

これからはじめる PostgreSQL入門

[改訂新版]内部構造から学ぶPostgreSQL 設計・運用計画の鉄則 (Software Design plus)

[改訂新版]内部構造から学ぶPostgreSQL 設計・運用計画の鉄則 (Software Design plus)

参考リンク

記事だけよんでわからなかった部分を調べた時に読んだページ

morizyun.github.io

qiita.com

www.slideshare.net

将太の寿司について

この記事は沼アドベントカレンダーの22日目です

私が起きている間は22日ってことにしてください。本当にごめんなさい

adventar.org

20,21 日目がまだ更新されていないですが、それぞれ興味深い沼ですので更新を楽しみにしております...!

で、なんで将太の寿司?

最初、ニンジャスレイヤーTLに流れてきて迷い込んだ別の沼(FGOやデスペラードとか)の話をしようと思ったのですが、将太の寿司の部分だけ異常な熱量になってしまったので、開き直ってそれだけ単発で話すことにしました

将太の寿司とは

manga-zero.com

基本的には、笹寿司という悪い寿司屋が主人公将太の妨害をして、将太はそれを工夫と出会う人々への想いで乗り切りながら、寿司コンクールの優勝を目指すという王道ストーリーなのですが、少年漫画というフォーマットのせいか、笹寿司の悪事が度を超えているのに衝撃を受けました

どのくらい悪いかを端的にまとめられていた記事があるので引用します

f:id:kasei_san:20181223011923p:plain
笹寿司の悪行

なお、上記の記事は、笹寿司のあまりの悪行のためにTLが「笹寿司許さない」で埋まったことに驚いた 実在の京都の寿司屋「笹寿し」に作者が謝罪に行く という、衝撃の記事です

実際のお寿司屋さんに影響を与えるなんて...、笹寿司のやつ、許さない...!

将太の寿司の本質

しかしながら、笹寿司の(おもしろ)悪事や、自然と一体化したり、電車にはねられた傷を1日で治す寿司能力者は、ストーリーの味付けに過ぎず、この将太の寿司の本質は 人への想い なんですね

基本的に主人公の将太くんの握るお寿司は、素朴でありながら、食べる人の想いに応える寿司です。それが手技だけを誇る職人を超えた温かみをお客さんと読者に提供してくれます

そういう意味では、本当にストーリーが「人の思いに温かみで応える」という感じで、王道中の王道なんですね....

(合間合間に差し込まれる人情物のサイドストーリーからも、作者の得意分野がそれであることを感じさせてくれます)

そして、最終話直前。そんな人のためにだけ寿司を握ってきた将太くんが、自らのために寿司を握ることが、去りゆく他者の道を未来に繋ぐことになると気がついたシーンで...! 私は泣きました...

そこからの全国大会編決勝戦。驚くことに握られた寿司の解説は一切ありませんでした。しかし、いままで50冊近く読んできた自分には、彼らがにぎった寿司の意味が...! 判りました...

こんなに読者を信頼した漫画があったでしょうか。全部で 44巻と非常に長いですが、そこまですべてを読んでこそ行き着く最終対決をみなさんもぜひ体験してください....!

今はマンガゼロで無料のようです

manga-zero.com

オチ

なお、自分のツイートを将太の寿司考察だらけにしたところ、会社の人に「かせいさんはなんだかわからないけどお寿司にハマっているのだな」と思われてしまい、退職の送別の品が魚のおもちゃになったのは一生の思い出にします

ここから胡乱

将太の寿司。期間限定無料配信だったために、将太の寿司を1日に10冊以上読んで、寝て寿司の夢を見て、通勤電車で将太の寿司のことを考えていくうちに、私は将太の寿司しんじつに目覚めました....!

結果的に、将太が宇宙生物に対して寿司を握るという二次創作をtwilogに上げたのですが...

togetter.com

トゥギャッター編集部の人、こんな記事をおすすめにして、いろいろ大丈夫ですか?

まとめ

将太の寿司という単一作品の話なので沼かどうか悩みましたが、ここまで味わい尽くしてなお楽しむ余地があるので、もう沼ってことで良いだろうと思いました

お寿司食べ行きたい

次回

明日は、最近お引越しをなさって壁一面マンガ本棚を絶賛作成中きよそねさんが、語る漫画沼です!

超楽しみ!

AWS DMS おぼえがき

これはなに?

AWS DMSについてざっくり概要を理解したので、忘れないように書いたメモです

AWS Database Migration Service(簡単、安全なデータベース移行)|AWS

先にまとめ

  • AWS DMSは、最小のダウンタイムでデーターベースの移行をしてくれるサービス
  • テーブル定義の移動はしてくれないので、予め移行するか AWS SCT か mysqldump などを使う
  • 移行後も変更に追従してくれるので、切替も切戻しもローリスク&最小ダウンタイムで実行可能

AWS DMSってなに?

AWS Database Migration Service

  • 既存のDBを最小のダウンタイムで他のDBに移行できるサービス

一番の特徴は?

異種間(OracleからMySQLなど)のDBの移行をサポートしていること

  • 同種間の移行もサポートしているが、性能や精度はオフィシャルのmigrationツールのほうがよいとのこと

「基本的に同種データベース間では、そのデータベース純正のレプリケーションツールの利用を推奨している。DMSでは内部構造的に、各種データベースの差分を吸収するため、一度データをDMS特有のデータ構造に変換していることから純正ツールに比べてどうしてもパフォーマンス的に不利になる。

AWS DMSでできることはなに?

以下の2つ(どちらかのみの実行も可能)

  • Full Load
    • データの移行
    • 全テーブルを1万行づつselectして、移行元に書き込む
    • メモリが不足すると、EBSにswapされるので、データサイズに合わせたメモリが合ったほうが良い
  • Change Data Capture(CDC)
    • データの変更に追従
    • トランザクションログを5秒毎にCaptureして、変更内容をSQLに置換して、変更元に書き込む
    • Full Load中や、変換が追いつかない場合キューイングされる
    • 変更が多い場合は、マシンの性能/台数を上げる必要がありそう

制限はある?

  • 元DBのエンジンのバージョンに制限あり

f:id:kasei_san:20181217130810p:plain
2017年資料なので少し古いかも

  • UTF8MB4はサポートしていない
    • MySQLだと致命的ですね...

docs.aws.amazon.com

  • その他DBのサイズなどに制限あり

docs.aws.amazon.com

DMSでできないことはある?

テーブル定義の移動

  • セカンダリインデックス、非プライマリーキー制約、デフォルト値などはサポートしておらず、移行先のDBに予め定義しておく必要がある

テーブル定義の移動はどうするの?

異種間の場合、AWS Schema Conversion Toolを使う

  • 同種間の移動なら、mysqldump などで移行できる

AWS SCTとは?

異種間のテーブル定義の移行をサポートしてくれるツール

docs.aws.amazon.com

AWS DMSでのDB移行の具体的な流れ

  1. 移行元DBの準備
  2. 移行先DBの準備
  3. DMSの設定
  4. 移行
  5. アプリ側の移行

移行元DBの準備

上述した、AWS SCTや、mysqldump などでテーブル定義を予め移行しておく

移行先DBの準備

  • VPN外の場合、インターネットに接続できるようにする
  • AWS内の場合、DMSが接続できるようにセキュリティグループを設定する

Full Load時に負荷がかかるので、専用のリードレプリカを用意したほうが良いと思う

DMSの設定

  • DMSのインスタンスタイプを決める
    • 性能が良い/台数が多いほうが当然移行が早くなる
      • 予め予行演習しておくと良いかも
    • FullLoadでメモリを食いそうな場合はメモリサイズを大きくしたほうが良い
    • CDCの頻度が高い場合も、マシンの性能/台数を増やしたほうが良い
  • DMSに接続する、移行元&移行先のDBのエンドポイントを用意する

移行

FullLoadと、CDCが行われることを見守る

アプリ側の移行

  1. 移行元DBへの書き込みを停止(ここからダウンタイム)
  2. 書き込みが完了したことを確認
    • AWS的では、最後に書き込まれるマーカートランザクションの使用を推奨している
  3. アプリのDBの参照先を移行元DBに変更(ここまでダウンタイム)

ダウンタイムを減らすのに良い方法はある?

CDCが始まった時点で、読み込みについては、移行元に変更したら良さそう

  • 書き込みのある処理だけダウンさせるという方法が取れるため、ダウンタイム発生が一部機能だけにできる
  • 予め読み込み部分だけでも、移行が正しく行われているかテストできる

Railsで読み込みだけ別DBにするのってどうするの?

いくつか方法がある

  • 案1. 読み込み/書き込みをAPI経由にして、それぞれ別々のDBを参照できるようにする
    • マイクロサービス化
  • 案2. 複数DBに対応のためのgemを導入する
  • 案3. Rails6を待つ

移行事例

PostgreSQL → PostgreSQL

  • DMSを使うことで旧verから低リスクで移行できたというお話

speakerdeck.com

MySQL(5.7) → Aurora(MySQL互換5.6)

  • 当時まだAuroraのMySQL互換が5.6しかなかったので、ダウングレードが必要だった

developer.feedforce.jp

社内LT大会(FFLT)で、転職活動のふりかえりについて話してきました

FFLTとは

弊社フィードフォースが不定期に行っているLT大会です

くわしくはこちら

developer.feedforce.jp

先日退職エントリを書いたので、それに合わせて転職活動のふりかえりについて話してきました

発表資料

参考資料

さあ、才能(じぶん)に目覚めよう 新版 ストレングス・ファインダー2.0

さあ、才能(じぶん)に目覚めよう 新版 ストレングス・ファインダー2.0

blog.kasei-san.com

blog.kasei-san.com

感想の付箋

f:id:kasei_san:20181217095843p:plain

いままで本当にありがとうございました...!

以上です!

株式会社フィードフォースを2018年いっぱいで退職いたします

feedforceアドベントカレンダー8日目! まさかの退職エントリで参加です! adventar.org

7日目はマスタカさんの健康的な記事でした! 私も最近ジムサボりがちなので、そろそろ再開したいですね...

masutaka.net

なんでフィードフォースに来たの?

2009年9月。web2.0ブームの頃にweb業界にあこがれて、SIerから株式会社フィードフォースに転職しました

フィードフォースで何やってたの?

約9年間、サテライトサイト構築サービスと、データフィード運用サービス のエンジニアをやっていました

Railsエンジニアとして入社しましたが、サテライトサイト構築サービスでも物理サーバと格闘したり、データフィード運用サービスでも lambda や ECS をいじったりと、必要に応じていろいろやっていました

個人的には「バッチエンジニア」という呼び名が一番しっくりくるのかなと思っています

最終的には、技術をバリバリに突き詰めると言うよりは、所属するプロジェクトのエンジニアチームをとりまとめたり、カンバンをつくるなどの業務改善をやりながら、コードも書くといった立ち位置でやっていました

9年間務めてどうでした?

KPTで

Keep

  • ボンクラSIerだった自分をいっぱしのエンジニアに育てて頂いたことには感謝しかありません...(本当に入社当初はポンコツでした...)
  • Ruby/Railsだけではなく、サーバの運用にも関われていろいろな経験が積めた(オンプレからECSまで!)
  • 若手からベテランまで、やる気にあふれて優秀な方が多く、本当にいろいろな刺激をいただきました...! 他の会社だったら多分ここまで自分は成長できなかったと思っています
  • 2回ほど社内の賞もいただきましたし、長く居た程度には社内に貢献できた...と思われていればよいな...

f:id:kasei_san:20170608194402j:plain
写真は賞をやり取りしてたのしそうなおじさんたち

Problem

  • 最初数年がボンクラすぎました。スキルと言うより、自分の欠点や素質をまっすぐ見ることが出来なかったのが原因でした
  • 9年は居すぎたかな...と思っている
    • その分得るものも沢山ありました
    • 本当にみなさんステキな方が多くて、今後もプライベートでも仲良くやれそうな人も沢山できた
  • Railsエンジニアではない
    • 自分がその環境を望まなかったのが原因でした
    • viewやフロントエンド、DB関係の知識が足りず、バランスが悪い

Try

  • Railsを一通りできるようにしたい
  • 新しい環境で、今まで得たものを放出しつつ、新しいものを得ていきたい
  • 退職後おちついたらフィードフォースボドゲ部 に遊び行く

どうして退職したの?

上記にもあるように、「9年は長く居すぎた」と「Railsの経験を一通り積みたい」が大きいです

新しい環境を作らないと新しい物を得ることもできないし、こちらが得たものも放出できないとも考えており、 feedforce在籍中にも、副業で他社スタートアップを手伝ったりして、よりその考えがより深まりました

今後は、新しい環境に積極的にTryして自分を高めつつ、新しい環境で得た経験で、そこで価値を提供できるようになれたらいいなぁ...と考えています

安住しやすい性格なので、本当にそこを意識しないと、安住しているうちに一生が終わりそう

つぎどこいくの?

株式会社LCLに転職します

www.lclco.com

日本最大級の高速バス検索サイトを運営しています BtoCも未経験なので楽しみ!

www.bushikaku.net

こちらで、Railsを一通りできるようになりつつ、インフラ部分で貢献していきます!

ほしいものリスト

退職エントリといえば...的な感なので上げてみます

こちらになります

最後に会社のみなさんへ

twitterや、このblogで好き勝手に発信していると思いますので、いつでも気軽にお声がけくださいー

本当にいろいろおせわになりました!

フィードフォースではエンジニアを募集しております!

レベル高くてやる気にあふれた人が沢山います。残業も殆ど無いし、週一リモートワークもチームによってOKなのでぜひ!! (あと、そこまでバリバリしたベンチャー感がなく、「普通の会社」なのでそこも個人的には好きでした)

www.wantedly.com

Amazon Auroraへの移行事例をまとめて知見を抽出してみた

先に知見まとめ

急いでる人はここだけ読めば良いと思う

移行方法

以下の3つの方法のどれかで移行している

  1. RDSの場合、Auroraリードレプリカを作成して、同期完了後、昇格
  2. Amazon DMSでAuroraにデータを移行。同期完了後、切替
    • DMSにはいくつか制限があるので、単純に移行はできない
  3. 自前でAuroraのmasterにレプリケーションを貼る。同期完了後、切替
    • 切替は設定ファイルのエンドポイントを書き換える or DNSのレコード変更

レプリケーションやDMSを使う場合、ついでにテーブルのリファクタリングをしている会社も多い

RDSなら、リードレプリカで移行するのがシンプル
それ以外からの移行 or テーブルのリファクタリングもしたいならば、DMSを使うのがベターか

やったほうが良さそうなこと

  • 段階的な移行として、旧DBとAuroraの同期が完了後、読み込みだけAuroraにする
    • 確かにその方が安全性が高そう
  • stageだけ先にAuroraに移行して検証する
    • その際に移行にかかる時間を計測しておくと、ダウンタイムが予測しやすくなる
  • 失敗時の切り戻しプランを用意する
  • 書き込みの切替時には、旧masterからの書き込みトラフィックを遮断する
    • セキュリティグループで対象のボートを閉じるのが簡単そう
  • カスタムエンドポイントで、バッチや検証用DBなど高負荷のreadが発生するトラフィックと、webサービスが使用するリードレプリカを分ける
  • 旧DBとAuroraのタイムゾーンをあわせる
  • Auroraのフェイルオーバー時のコネクションプーリング対策

その他

  • 現在は、Aurora(MySQL5.7)があり、Performance Insightsもサポートされている

各社の移行事例

BASEのメインDBをAurora(MySQL)に移行しました - BASE開発チームブログ

  • 一番最新っぽい事例

記事執筆時期

2018/11月

移行内容

  • RDS(MySQL5.6) -> Aurora(MySQL5.6)

移行理由

  • 運用負荷の削減
    • MySQL on EC2の方が多機能だがスキルのあるエンジニアを貼り付ける必要がある
    • MySQLの新機能と、RDSのスループットのトレードオフ
    • ベンダーロックインというリスク
  • 速度
    • レプリカラグが発生しない
    • クエリキャッシュが有用
    • スループットの向上
  • 費用(分析、集計用DBをリードレプリカに移行できたため
  • その他Auroraの機能
    • カスタムエンドポイント(分析用レプリカを運用していた
    • 無停止パッチ(運用コスト削減
    • Performance Insights
    • 監査ログ
    • 高速クローン

移行方法

  • 既存環境からAuroraのMasterにレプリケーション
    • テンポラリの書き込み可能MySQLレプリカを間に挟んでいる

サービスに影響しない書き込み可能レプリカを入れることで、「mysql.rds_stop_replication」と「mysql.rds_start_replication」コマンドにてレプリケーションを操作し、レプリケーションを止めている間にテンポラリに対して巨大テーブルへのALTER文等を実施して事前にAuroraのテーブル定義をカスタマイズできます。弊社で言えば大きめのテーブルへのインデックス追加はこのやり方で実施しておきました。row_formatをDynamicに書き換えておきたい場合などはこの方法で実施すれば夜間メンテなどで長い時間サービスを停止する必要なく実施できます。

  • CNAME内のエンドポイント情報を全てAurora側に向けることで移行

移行結果

  • リードレプリカのタイムラグが減った

特記事項

  • Aurora Serverlessの検討
    • インスタンス用パラメータグループにあるinnodb_file_formatでbarracuda指定ができないので見送り
    • barracudaはファイルを圧縮して、IOスループットを上げるオプション
  • MySQLのバージョン
  • テーブル圧縮はコマンドが通るけど実際には圧縮されないので気付きにくいらしい

MySQLからPostgreSQLへの移行とDBリファクタリング/postgresqlJapan2018 - Speaker Deck

記事執筆時期

2018/11月

移行内容

Aurora(MySQL) -> Aurora(PostgreSQL)

移行理由

RDBのリファクタリング

  • PostgreSQLへの移行理由
    • トリガーを柔軟に定義できる
    • トリガーに指定するユーザー定義関数の言語が複数選択できる

移行方法

  • Amazon DMSを使用
    • レプリケーションのタイミングでDBトリガーを発動し、リファクタリングしたテーブルに合わせた内容にデータを加工している
  • APIサービスを新たに立ててDBへのアクセスをAPIにwrap
    • API内で、徐々に新DBに移行

特記事項

  • 移行失敗の監視
    • Mackerelのチェックプラグインを使用
    • エラーログを監視して何かあったら通知
    • CloudWatchでできそうな...?

RDS for MySQLからAuroraへの移行 〜Auroraリードレプリカを利用した低コスト移行方式〜 - コネヒト開発者ブログ

記事執筆時期

2018/8月

移行内容

  • RDS(MySQL5.6) -> Aurora(MySQL5.6)

移行理由

  • 可用性を担保しながら、コストメリットが享受できる
  • 運用面のメリットを享受したかった

移行方法

Aurora リードレプリカ -> masterへ昇格

  • Auroraリードレプリカを本番の読み取りトラフィックにカナリアリリース
  • ステージング環境を、Aurora構成に切替
  • 本番の読み取りトラフィックを100%Aurora化
  • サービス用途以外のレプリカDBを、Auroraをマスターとするbinlogレプリにて作成
  • 書込トラフィックのAuroraへの切替
    • 書き込みトラフィックを遮断

      切替時の書込データロストを防ぐ為の書込トラフィック遮断 RDSマスタをリードオンリーモードにするのが正攻法なところですが、SecurityGroupを使い、L4レイヤでMySQLへの通信を遮断する方法を選択しました。

    • 最終書込のAuroraへのレプリケーション確認
    • Auroraマスター昇格
    • 書込トラフィックをAuroraへ切替

特記事項

  • 書き込み切替のダウンタイムは3分強
  • 「複数のリーダエンドポイントを設けたい」と書かれているが、現在はカスタムエンドポイントで対応可能

Aurora リードレプリカを使用した PostgreSQL から Aurora への移行 - TerraSkyBase

記事執筆時期

2018/8月

移行内容

RDS(PostgreSQL) -> Aurora(PostgreSQL)

移行理由

なし。検証

移行方法

Aurora リードレプリカ -> masterへ昇格

  • Aurora リードレプリカの作成
    • RDSのリードレプリカとして設定する
  • 同期完了後に昇格
    • ドキュメントでは Aurora リードレプリカのレプリカラグを"0" にするとあるが、実質不可能なので、トランザクションを停止させてから昇格した
  • DB クラスターロールが、「レプリカ」から「マスターになる」

雑感

EC2上のMySQLからAuroraへの移行作業で失敗・想定外だったこと - シンクロ・フード エンジニアブログ

記事執筆時期

2018/5月

移行内容

EC2上の MySQL -> Aurora(MySQL)

移行理由

不明

移行方法

自前でAuroraのmasterにレプリケーションを貼る。同期完了後、切替

特記事項

  • Aurora→外側のMySQLサーバという向きではレプリケーションがSSL通信できない
    • 別リージョンのMySQLサーバにバックアップを取っていた
    • 結局クロスリージョンレプリカを使用
  • 移行前のMySQLサーバと、移行予定のAuroraサーバのTimezoneがズレていることにより、移行当日のデータ差分チェックで差分が発生
  • フェイルオーバー後、クライアント側のコネクションプーリングが、新リードレプリカをmasterと誤認する
    • rails側でコネクションプーリングを定期的にリセットするように設定したらしい

RDS for MySQL5.7 から Aurora(MySQL 5.6 互換)へ移行しました - Feedforce Developer Blog

  • へいしゃblog

記事執筆時期

2017/10月

移行内容

RDS(MySQL5.7) -> Aurora(MySQL5.6)

  • 当時はMySQL5.7未サポート

移行理由

ストレージの自動スケーリング 、耐障害性 という主に運用目線で見たときの強みを評価し、採用しました。

移行方法

既存 DB を RDS へ最小限のダウンタイムで移行することができる AWS Database Migration Service (以下 DMS) を利用して、データ移行を行いました。

  • Auroraを参照する環境を新しく作成して、BuleGreenDeploymentで移行

特記事項

  • MySQL5.6 -> 5.7へのダウングレード
    • 影響範囲の調査が必要だった
    • ROW_FORMAT が変わるので、migrationを用意して、db:migrate した
    • mysql-devel のバージョンを 5.7 から 5.6 にダウンさせる必要があった
  • DMS
    • Terraformでコード化しなかったけど、コード化した方が安全だった
    • null 制約 や AUTO_INCREMENT 属性といった情報は移行されないので、mysqldump でテーブル定義だけ先にdumpした
    • 外部キーが設定されたテーブルのデータ移行が失敗することがあるので、追加の接続属性 に initstmt=SET FOREIGN_KEY_CHECKS=0 を追加
  • 所要時間の把握が不足していた。事前にリハーサルを行って把握しておくべき

【ヒカラボ】RDS for MySQL → Aurora

記事執筆時期

2016年1月

  • AmazonDMSリリース前

移行内容

RDS(MySQL5.6) -> Aurora

移行理由

  • パフォーマンスの向上
  • メンテナンスの削減
  • 負荷対策(リードレプリカ15台)
  • コスト削減

移行方法

RDSのリードレプリカからスナップショットを作成後、RDS->Auroraにレプリケーションを貼る

  • その後、参照系、更新系と、Auroraに移行
  • 移行後、切り戻しができるように、逆方向にレプリケーションを貼り直した

移行結果

  • パフォーマンスは目立つほど向上していない
  • インスタンス作成時間が短縮された

特記事項

  • writerインスタンスを再起動すると、フェイルオーバーが発生することがある
  • 昇格を前提にした設計に変更した
    • インスタンス名を昇格を前提にした名前に変更した
      • db-master db-slave01.. を instance001, instance002... )
    • readerとwriterのセキュリティグループを統一

その他の移行事例