oinume journal

Scratchpad of what I learned

dmm-eikaiwa-tscにバグ

以前紹介したDMM英会話でお気に入りの先生の空きレッスンが登録されたらメールで通知するヤツにバグがあったので、使っている人がいたらアップデートお願いします。

バグの内容はレッスン講師のスケジュール表に「休講」というステータスが出現したため、スケジュール表のスクレイピングに失敗して、Heroku Schedulerで動いているアプリケーションがエラーで止まるというものです。詳細は以下を参照してもらえればと。

bin/fetcher aborts with "Unknown schedule text:休講" · Issue #25 · oinume/dmm-eikaiwa-tsc · GitHub

今Herokuで動いているアプリについてはアップデート方法をREADMEにまとめておきました。簡単に言うとdmm-eikaiwa-tscリポジトリgit cloneしてgit push heroku masterする感じです。

ボタンワンクリックでHerokuにディプロイできるようにはしてあるのですが、このようなアップデートをいかに簡単にディプロイするかは課題ですね...

Parsing MySQL's URL in Python3

Just add urllib.parse.uses_netloc.append("mysql") if you want to parse URL such as mysql://root:pass@localhost/demo.

#!/usr/bin/env python

import urllib.parse
urllib.parse.uses_netloc.append("mysql")

if __name__ == "__main__":
    url_str = "mysql://root:pass@localhost/demo"
    url = urllib.parse.urlparse(url_str)
    print("URL={0}".format(url_str))
    print("host={0}, user={1}, password={2}, database={3}".format(
        url.hostname, url.username, url.password, url.path[1:]))
$ python3 url_parse.python
URL=mysql://root:pass@localhost/demo
host=localhost, user=root, password=pass, database=demo

DMM英会話でお気に入りの先生の空きレッスンが登録されたらメールで通知するヤツ作った

2016/11/25追記

後継のlekcijeというサービスを作ったのでぜひこちらをご利用下さい。

www.lekcije.com

動機

  • どのSkype英会話でもそうだと思うんだけど、人気のある先生はすぐ予約が埋まっちゃう
  • でもスケジュールをいちいち検索してチェックするのはダルい

というわけで作りました。

使った技術

github.com

ソースコードは↑。"Deploy to Heroku" buttonをつけておいたので、Herokuアカウントがあれば誰でもこのアプリケーションを使うことができる。やり方はREADMEを見てもらえればと。

概要

  • Heroku Schedulerで10分おきにお気に入りの先生のスケジュールのページをスクレイピング
  • 前回のスケジュール(DB)と今回スクレイピングしたスケジュールを比較
    • 新しく空きレッスンがある場合はメールで通知
  • スクレイピングしたスケジュールをDBに登録
  • スケジュールをチェックしたい先生のIDを入力する画面を作るのが辛かったので、その辺は環境変数経由でIDを渡すという手抜きな構造
    • 超ヒマになったら画面作りたい

結果

人気の先生の予約がめっちゃ取りやすくなったし、副次的な効果としてキャンセルで空いたレッスンにもすぐ気付けるようになったので、DMM英会話やってる人は使ってみたらいいと思います。

どんどん話すための瞬間英作文トレーニング (CD BOOK)

どんどん話すための瞬間英作文トレーニング (CD BOOK)

余談

これを作り始めてからGitHubに草が生えるようになった。

commits of github.com

今回は小規模だったためORMapperなどのライブラリ・フレームワークを使わないで実装したけど、会社だけでコードを書いているといかに自分がフレームワークやライブラリに依存したコードしか書けないかを思い知らされて良かったです。

まだ3大キャリアSIMで消耗してるの?MVNOのススメ

Docomo iPhone6 + IIJ mioに乗り換えてから3ヶ月ぐらいたったのでその使用感をば。結論から言うと今すぐキャリアSIMやめてMVNOに切り替えた方がいいと思う。

料金が安い

SoftbankからIIJ mioに切り替えてから、月々の利用料金が約半額になった。具体的には、Softbankの時は平均で6000円ぐらいだったのが、今では3000円以下になってる。年で考えると36000円のコストカットになるのでこれはデカい。ちなみに契約しているのはデータ通信量が3GBのミニマムスタートプランに音声通話機能をつけてる。

ちなみにこれは10月の料金明細。

スクリーンショット 2015-11-29 0.34.52

200Kbpsでも意外とイケる

自分はTwitterを見ることが多いんだけど、Twitter、メール、ネットを見るぐらいであれば200kbpsでもそこまでストレスなく見れる。なので必要なとき以外はクーポンをOFFにして200Kbpsの低速回線を使うようにして、3GB/月の通信量でおさまるようにしてる。IIJ mioだとみおぽんというアプリを使うことで簡単にクーポンをON/OFFにして回線速度を切り替えられる。自分はWebエンジニアなので、あえてクーポンをOFFにして200Kbpsの回線で自分が運用しているサイトがストレスなく閲覧できるかもチェックしてる。

あと、iOS向けのGoogle Chromeを使えば、Googleのサーバーから最適化された状態でサイトを閲覧することができるので、低速回線だとSafariよりもブラウジングが快適になる。

さらに余ったデータ通信量は翌月に繰り越せるのもいい。

回線の品質がいい

MVNOなので混雑時つながりにくいことがあるかと思いきやそういうことはなく、Softbankauなどのキャリアの回線と比べても遜色ない気がする。この3ヶ月間で「あ、なんか回線が詰まってるな」と思ったのは3,4回ぐらいだ。

端末

Apple Storeで売っているSIMフリーiPhone6(128GB)は約12万と高いので、じゃんぱらで中古のDoCoMoのiPhone6を7万円で買った。だいたいのMVNOはDoCoMoの回線を使っているので、バカ高いSIMフリー端末じゃなくてもOKっていうのは意外と知られていないっぽい。

まとめ

というわけでまだ3大キャリアSIMで消耗している人は今すぐMVNO SIMに切り替えましょう。このリンクからIIJ mioに申し込むとデータ通信量が2ヶ月間10%増量されます。

IIJ IIJmio SIM 音声通話 パック みおふぉん IM-B043

IIJ IIJmio SIM 音声通話 パック みおふぉん IM-B043

Amazon RDS for Aurora 東京ローンチ記念セミナー

Auroraの検討を導入していることもあり、11/10のAmazon RDS for Aurora 東京ローンチ記念セミナーに行ってきたのでそのメモ書きと感想。

Debanjan Saha, GM, Amazon Aurora

Auroraチームの人。AuroraはAWS史上最速で成長しているサービスと言っていた。

エンタープライズ顧客の要望リスト

  • 専門家部隊がいなくても運用・管理できる
  • ライセンス管理しなくてもいい

MySQL互換のリレーショナル・データベース

  • 商用DB並のパフォーマンスと可用性
  • OSS DBの使いやすさとコスト効果
  • 3箇所のデータセンターに6つの複製を保持
  • 30秒以内でフェールオーバー
  • 50万 Read IOPS
  • 10万 Write IOPS
  • 64TB Storage - DBに最適化したストレージ

Aurora使っている会社

  • Expedia
  • GE Oil & Gas
  • Alfresco

などなど。

Expedia

  • 現行のSQL Serverベースのアーキテクチャはデータボリュームの増加と共にパフォーマンスの低下が見られた
  • Cassandra + Solrを組み合わせたインデックスは大きなメモリー空間を必要としてコストを押し上げた
  • Auroraはスケーラビリティとパフォーマンス要件を満たし、コストもずっと低かった
  • 平常時25K INSERT/sec (Peak 70K)
  • 平均レスポンスタイムはWrite 30ms, Read 17ms

PG&E

  • 天然ガス+電力の公益企業
  • 電力関係のイベントが起きた際に突発的なトラフィックを処理しなくてはいけないという課題
  • データベースが落ちた時の影響が大きい
  • 遅延のほとんどないRead Replicaを複数持つことができるため、電力化kん京のイベントが起きた際の突発的なトラフィックを処理し、顧客に最新の情報をタイムリーに提供できるようになった

ISCS

  • 保険請求処理
  • Oracle + SQL Serverを通常業務ならびにウェアハウスデータ用に使用
  • コストが大きな支出となっていた
  • 余裕をもたせた状態のAuroraのコストがSQLServerの構成よりも70%やすかった
  • Auroraの連続的なバックアップ機能により、バックアップ処理ウインドウを廃止できた

ThreatStack

  • AWS顧客に対し連続的なセキュリティ監視を提供
  • 脅威分析のために大きく連続したデータストリームを扱う
  • 50万INSERT/sec, 1日の生データは10TB
    • Cassandraからの移行
  • Auroraを時系列データを扱うDBとして使用

Architecture

  • Three AZ and 6 data replica
  • Quoram
  • Peer-to-peer gossip Replication
  • Continuous S3 backup
  • Storage node check and failure and repair

高速なクラッシュリカバリ

  • 最後のチェックポイントからのログを適用する必要がある
  • AuroraはDisk readの一環としてオンデマンドでredo logの適用を行う
    • 並列・分散・非同期で行われる
    • 起動時に実行する必要がない

フェイルオーバー時間

  • Failure Detection(15-30sec), DNS Propagation(5-20sec)
  • Aurora + MariaDB Driverを組み合わせることにより30秒未満でフェイルオーバーできる

バックアップ

  • 通常のデータベースはバックアップウィンドウの時間があるが、Auroraは継続的にバックアップしている
  • DBサイズが大きければ大きいほど時間がかかる

なぜAuroraは速いのか

  • IOを減らす
  • ネットワークパケットを最小限にする
  • 結果をキャッシュしておく

Advanced Monitoring

  • より詳しいOSの統計情報がとれるようになる予定
  • 1秒単位でメトリクス取得可能

お金の話

  • No idle standby instance
  • Single shared storage volume
  • NO POIPs - pay for use I/O (Provisioned IOPSが不要)
  • 21.4% Savings
  • さらにパフォーマンスがいいので、MySQLおり小さいインスタンスでもいいかも

質疑応答

  • MySQLだとデータ量が多いとAlter tableが遅い問題
    • Online DDLについては改善予定(3-6ヶ月以内)
  • r3以外のインスタンスについて
    • t2 instanceについては検討中
    • mやcのタイプはあまり検討していない
  • メモリに乗らないAlter tableはOOMが出る?
    • 大体の問題は対応済み
  • MHAのような数秒単位でのインスタンス入れ替えは可能?
    • できないので、Read replica作ってそこにフェイルオーバーさせる

RDS for MySQLからAuroraへの移行

ラニ吉崎さん

スライド

どのような変化があったか

  • UPDATEの高速化(16.2ms -> 2.84ms)
  • INSERT(2.9ms -> 1.3ms)
  • DELETE(0.8ms -> 1ms)
  • SELECTはあまり変わってない

Migration

  • Amazonの移行ガイドを読む
  • 移行方法
  • SQL_Modeは0にする

SNAPSHOT Migration

  • 120GB: db.r3.4xlarge
    • マイグレーション素養時間:01:37h
    • レプリカ作成所要時間  :00:06h(これは常に6分!!)
  • 1100GB: db.r3.8xlarge
    • マイグレーション素養時間:10:42h
    • レプリカ作成所要時間  :00:06h(これは常に6分!!)

Replication Migration Summary

Cluster & DB Parameters

High CPU / Memory / QueueDepth

  • RDS for MySQL: 60%声から著しい性能劣化
    • Connnection拒否や応答しないなど

今後に期待したいこと

  • Failover order
  • Mandatory Cache purge

ドワンゴがAurora使ってみた(仮)

ドワンゴでの開発

  • 多数のサーバーやネットワーク機器
  • サーバーはHWから自作しようとしてる

AWS導入サービスの増加

  • Dwango Reader
    • アプリケーションレイヤーで水平分割
    • 大量の記事データ

Aurora

  • 空き領域の再利用は効率よく行われている
    • 3.05% -> 2.67%
  • パフォーマンス
    • 最大64TBまでシームレスにサポートされる点の安心感
  • MySQLとの互換性はLDRとしては十分

ウルシステムズの漆原さん

Oracle使ってるようなエンプラからの移行

  • モノリシックなアーキテクチャ
    • 顧客テーブルをみんな参照しているとかw
    • DB変更に弱い。何箇所も影響あり
  • マイクロサービス化でさらなる効果を
    • 特定の技術にロックインされない(でもカオスになる可能性もある)

マイクロサービスについて

  • JSON/REST, HTTP
  • エラー処理
  • キャッシュ
  • サービスモニタリング
  • 統一のログ取得
  • 独立したディプロイ

Aurora活用のステップ

感想

現在開発環境でAuroraを試していて、アプリケーションは一切いじらずに普通に稼働していてMySQLとの互換性の高さを感じている。あとはALTER TABLEした時の挙動とか負荷試験をして問題なければ導入する予定。

Auroraを導入するメリットとしては

  • 事前にディスク容量やIOPSを考える必要がない(勝手に拡張されていく)
  • Master/Slaveは同じデータを見ているので運用が楽になる
    • レプリケーションを考えなくていいので、精神的にもストレスがなさそう
    • Slave(Read Replica)を作るのが一定の時間で終わる
  • コストメリット
    • 事前にEBS容量を確保しなくていいので無駄がない
  • 書き込みが速くなる

などかなぁと思ってる。でで、特にAuroraへの移行の話は参考になって、データ容量が少なければスナップショットからの移行が一番楽そうだなと思っているところ。

とにかくMySQLを利用するような値段でWrite10万IOPS出るようなDBが使えるのはすごい。これはもうFusionIOとかいらなくなる予感がしている。