どこのとは明記しないけども
・ドメイン取得の件
その取得価格を前面に押し出しているように見えたけど、それをアピールする意味はどういうところにあるのだろう。取得価格なしで書いてもいいんでないの？と思ったのだけどマーケティングや広報としては記載するのが良い材料なのかしら。
・新卒採用の半数を外国人に
これはプレスでなくてニュースでみかけた。前いた会社は日本の企業だったけど、特にニュースになることはなく自然と第一言語が日本語でない方（「外国人」という書き方は個人的になんだかしっくりこないけど多分そのほうが書きやすいよね）の採用は増えていたので、ニュースになるのが却って気持ち悪く感じた。
「グローバル化」を謳っている最中の会社だとそういうパタンもあるということか。
ヘッドカウント半数達したからこっちの枠はストップ、というのがあるのかなぁ。
敢えてどの国がルーツかという点で書くと、第一言語が日本語でないこれまで会ったことのあるエンジニアでとんでもなくすごいと思ったのはインドの方。
2014年11月23日日曜日
Aurora で思ったことなど
Amazon RDS for Aurora (Preview)
Aurora on Amazon RDS
FAQをさらっと見る
http://aws.amazon.com/jp/rds/aurora/faqs/
特徴や for MySQL と異なる点など
MySQL 互換
ストレージエンジンは InnoDB のみ
sysbench で MySQL と比べて5倍高速
ストレージサイズは自動拡張。64TBまで
自動バックアップは性能に影響を与えない。スナップショット取得も。
データベースのボリュームは10GB毎のチャンクに自動的に分けて保存される。（これをユーザが意識する必要はない）
クラッシュ後のリカバリで redo ログを実行する必要がないのでほぼ1分程度で復旧する。
バッファキャッシュ(InnoDB の buffer pool でしょうな)はプロセスの外にあって再起動時に利用されるので buffer pool の warm up が必要ない。
リードレプリカを15基まで作成可能
クロスリージョンリードレプリカは現在未サポート
http://aws.amazon.com/rds/aurora/pricing/
Pricingをみると、いまんとこ db.r3 ファミリーのみ。
一言でいうと余分なところを削ぎ落として独自にチューンした、という感じかな。
ストレージ周りはかなり異なっていそう。RR作成数が3倍だし、自動バックアップ/スナップショットで影響受けないと謳っているし、サイズも64TBまでだし。
Aurora でないとほんの 3TB ですよ。。
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html
SQL Server で PIOPS だと 1TB 。
2012/9 に PIOPS が利用できるようになり、
2013/3 に ストレージ容量、IOPS値が強化され、
その後 2013/6 に ベータがなくなった
ということからストレージ、ディスク I/O 周りについてはこれまでも改善の跡が伺える。
Aurora だとただ SSD と書かれているので Magnetic/General Purpose/PIOPS の選択はなく、別だよねぇ。
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Aurora.html#Aurora.Overview.Storage
--
Aurora data is stored in the cluster volume, which is a single, virtual volume that utilizes solid state disk (SSD) drives. A cluster volume consists of copies of the data across multiple Availability Zones in a single region. Because the data is automatically replicated across Availability Zones, your data is highly durable with less possibility of data loss. This replication also ensures that your database is more available during a failover because the data copies already exist in the other Availability Zones and continue to serve data requests to the instances in your DB cluster.
--
今の RDS for MySQL の IOPS上限は 30,000 なので、5倍、でもしや 150,000 IOPS ？？とするといわゆる PCIe なサーバサイドフラッシュを使ってるけどこの性能 overkill すぎぃ！& 冗長構成めんどくさっ！なところに新たにリーチするのかな。
DynamoDB のように Aurora もバージョン番号なぞないんだろうけど、MySQL側で incompatible change があった場合どうなるんだろう？
3年前から開発、というのは SSD やそれ周辺の単価が下がる「待ち」もあったのか、MySQL 5.6 が 2013年にリリースされるまで待つ期間もあったのか、どう作りこんでいったのかエンジニアリングが気になる。開発中 5.5 で作っていて 5.6 に移行したのか、2011年の時点で 5.6.2 でも使ってたのかしら。db.r3 ファミリーなんて恐らく当時は影も形もないだろうし、謎い。
Aurora on Amazon RDS
FAQをさらっと見る
http://aws.amazon.com/jp/rds/aurora/faqs/
特徴や for MySQL と異なる点など
MySQL 互換
ストレージエンジンは InnoDB のみ
sysbench で MySQL と比べて5倍高速
ストレージサイズは自動拡張。64TBまで
自動バックアップは性能に影響を与えない。スナップショット取得も。
データベースのボリュームは10GB毎のチャンクに自動的に分けて保存される。（これをユーザが意識する必要はない）
クラッシュ後のリカバリで redo ログを実行する必要がないのでほぼ1分程度で復旧する。
バッファキャッシュ(InnoDB の buffer pool でしょうな)はプロセスの外にあって再起動時に利用されるので buffer pool の warm up が必要ない。
リードレプリカを15基まで作成可能
クロスリージョンリードレプリカは現在未サポート
http://aws.amazon.com/rds/aurora/pricing/
Pricingをみると、いまんとこ db.r3 ファミリーのみ。
一言でいうと余分なところを削ぎ落として独自にチューンした、という感じかな。
ストレージ周りはかなり異なっていそう。RR作成数が3倍だし、自動バックアップ/スナップショットで影響受けないと謳っているし、サイズも64TBまでだし。
Aurora でないとほんの 3TB ですよ。。
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html
SQL Server で PIOPS だと 1TB 。
2012/9 に PIOPS が利用できるようになり、
2013/3 に ストレージ容量、IOPS値が強化され、
その後 2013/6 に ベータがなくなった
ということからストレージ、ディスク I/O 周りについてはこれまでも改善の跡が伺える。
Aurora だとただ SSD と書かれているので Magnetic/General Purpose/PIOPS の選択はなく、別だよねぇ。
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Aurora.html#Aurora.Overview.Storage
--
Aurora data is stored in the cluster volume, which is a single, virtual volume that utilizes solid state disk (SSD) drives. A cluster volume consists of copies of the data across multiple Availability Zones in a single region. Because the data is automatically replicated across Availability Zones, your data is highly durable with less possibility of data loss. This replication also ensures that your database is more available during a failover because the data copies already exist in the other Availability Zones and continue to serve data requests to the instances in your DB cluster.
--
今の RDS for MySQL の IOPS上限は 30,000 なので、5倍、でもしや 150,000 IOPS ？？とするといわゆる PCIe なサーバサイドフラッシュを使ってるけどこの性能 overkill すぎぃ！& 冗長構成めんどくさっ！なところに新たにリーチするのかな。
DynamoDB のように Aurora もバージョン番号なぞないんだろうけど、MySQL側で incompatible change があった場合どうなるんだろう？
3年前から開発、というのは SSD やそれ周辺の単価が下がる「待ち」もあったのか、MySQL 5.6 が 2013年にリリースされるまで待つ期間もあったのか、どう作りこんでいったのかエンジニアリングが気になる。開発中 5.5 で作っていて 5.6 に移行したのか、2011年の時点で 5.6.2 でも使ってたのかしら。db.r3 ファミリーなんて恐らく当時は影も形もないだろうし、謎い。
2014年11月16日日曜日
いにしえのマネージメントコンソール
MBP 内をファイルを片付けてたら前スクリーンショットとったのがあったので一部加工したうえで公開。単になつかしいだけだな。。
このころはバンバン failover していたような気がする... （** 当時はベータリリース。2013年6月までね！ http://jp.techcrunch.com/2013/06/07/20130606amazons-relational-database-service-hits-general-availability-gets-sla-with-99-95-monthly-uptime-promise/ ）
タブだったねぇ。その後サービス増えてタブじゃなくなった。
マネージメントコンソールの変化ぶりから UI/UX を考察しているひといないのかなー。
マネージメントコンソールの変化ぶりから UI/UX を考察しているひといないのかなー。
このころはバンバン failover していたような気がする... （** 当時はベータリリース。2013年6月までね！ http://jp.techcrunch.com/2013/06/07/20130606amazons-relational-database-service-hits-general-availability-gets-sla-with-99-95-monthly-uptime-promise/ ）
2014年11月15日土曜日
つどい x 2
11/13 (木)
某ソシャゲ会社 OB で集まり。不定期で何ヶ月おきかにしている。
いつもおなじメンツではなく多少変動ありで、近況報告、情報交換、世間話などなど。
Selenium をゴリゴリ使うのは気になった。なんか使えるかも。
11/14(金)
元同僚が取り締まっている会社の集いにお呼ばれし参加。前回は8月末におじゃました。今回も久しぶりに会えた人がいて元気にやってそうでなにより。
プロダクトの違いを聞けてなるほど納得。
ぐぐり力はやっぱり大事だなと思った。大抵のことは誰かすでにやっててなんかしら書いてるからねぇこの業界は。
ペンキ理論は同意。通しでやらないとね。
両日ともプログラマ率が高かったのだけど、やはりプロダクト作れるのはいいなと。
自分からみると「手に職」感が上と思う。いわゆる「前線」からは退いたので余計そう思うのかも。
今の職だと internal transfer で作る側に行く人いるよと何度か聞いてることもあり、中長期でなんかしら考えてみるといいかもしれないな。
某定年説だとすでに定年なのでアプローチの仕方は全く異なるだろうけど。
某ソシャゲ会社 OB で集まり。不定期で何ヶ月おきかにしている。
いつもおなじメンツではなく多少変動ありで、近況報告、情報交換、世間話などなど。
Selenium をゴリゴリ使うのは気になった。なんか使えるかも。
11/14(金)
元同僚が取り締まっている会社の集いにお呼ばれし参加。前回は8月末におじゃました。今回も久しぶりに会えた人がいて元気にやってそうでなにより。
プロダクトの違いを聞けてなるほど納得。
ぐぐり力はやっぱり大事だなと思った。大抵のことは誰かすでにやっててなんかしら書いてるからねぇこの業界は。
ペンキ理論は同意。通しでやらないとね。
両日ともプログラマ率が高かったのだけど、やはりプロダクト作れるのはいいなと。
自分からみると「手に職」感が上と思う。いわゆる「前線」からは退いたので余計そう思うのかも。
今の職だと internal transfer で作る側に行く人いるよと何度か聞いてることもあり、中長期でなんかしら考えてみるといいかもしれないな。
某定年説だとすでに定年なのでアプローチの仕方は全く異なるだろうけど。
2014年11月8日土曜日
Kindle 買い替え
Voyage に。そして Paperwhite (2013) は速やかに下取りへ。
もっさり感は更に改善した。
その価格もあって、解像度はあがりベゼルの段もなくなったりしててかなりよろしい。
画面がザラザラからツルツルになったのもよい。
画面がザラザラからツルツルになったのもよい。
カバーつけるとややゴツくなってしまうけどこれは仕方ないか。
2014年11月7日金曜日
なぜこの仕事をしているのか
ほぼサーバ周り「だけ」してきたのだけど、タイトルのことを聞かれると、はて、なんでだろうなと思ってしまった。
自分よりうまくやれるひとは多いし自分がやる必要あるか？と問われれば No なんだけど、これしかできなくなってしまっているからというのが大きいかな。
前に書いた通りキャリアについて考える機会が増えたのだけど、やはり20代のころにこのような環境にいることができたらかなり違ったろうなと思う。
ああ、すぐに40代がやってくるぞ。
Configure Command がない
php の話。php -i や phpinfo(); でみえない。
ひとまずは SRPM をとってきて spec みてどう configure してるのか分かったので解決。
その後、なんでだろなーと思って調べてみたら、ext/standard/info.c にパッチがあたっていた。下記行をコメントアウトするパッチ。
あとでわかったのが、php-devel いれれば php-config でみれるな。
あまりみる必要となることもないけど覚えておこう。
ひとまずは SRPM をとってきて spec みてどう configure してるのか分かったので解決。
その後、なんでだろなーと思って調べてみたら、ext/standard/info.c にパッチがあたっていた。下記行をコメントアウトするパッチ。
#ifdef CONFIGURE_COMMAND
php_info_print_table_row(2, "Configure Command", CONFIGURE_COMMAND );
#endif
あとでわかったのが、php-devel いれれば php-config でみれるな。
あまりみる必要となることもないけど覚えておこう。
登録:
投稿 (Atom)