gmomedia-engineer - Tumblr blog

gmomedia-engineer · 5 years

Text

(定期投稿)エンジニアブログは移転しました

GMOメディアエンジニアブログは移転しました！

https://blog.gmo.media/

現在はこちらのURLでGMOメディアクリエイターブログとして運用しております。新しいクリエイターブログをよろしくお願いします。

1 note · View note

gmomedia-engineer · 6 years

Text

エンジニアブログは移転しました

GMOメディアエンジニアブログは移転しました！

https://blog.gmo.media/

今後はエンジニアとデザイナーで作り上げる、GMOメディアクリエイターブログとして運用していきます。

新しいクリエイターブログをよろしくお願いします!

1 note · View note

gmomedia-engineer · 6 years

Text

8/20(月) Club MySQL #3に参加するはなし

ぬいぐるみが好きな方のDBAです。

来る 8/20(月) 、サイボウズさんのオフィスにお邪魔して Club MySQL の第3回、 yoku0825のつくりかたという話をさせていただくことになりました。

Club MySQL #3 ～ yoku0825 のつくりかた - connpass

Club MySQLは割と最近始まったMySQL関連の勉強会なので、東京でよく開催されるその他のMySQL勉強会とその特徴を比較して紹介してみたいと思います。

MyNA（日本MySQLユーザ会）会

日本MySQLユーザ会主催（？）の勉強会です

呼び方はマイナ会または日本マイエスキューエルユーザ会会、後者を略してカイカイと呼ぶ人もいます

MyNA=日本MySQLユーザ会 + 会なので、会会とダブるのは誤記ではないのです

過去の開催履歴はこちらから何となく一覧できます

Oracle MySQLの中の人からも日本のMySQLコミュニティーとして認知されているので、外国からMySQL開発チームの方が来日したりすると来てくれることが多いですね

ロングセッション x 3 + あればLT、という感じだと思います

ロングセッションは運営が探してくることが多いです

飲む人は飲みながら聞いてます、みたいな

MySQL Casual Talks

MySQL Casual主催（？）の勉強会

無印の東京版と in Fukuoka の福岡版があります

福岡版は来週、7回目のMySQL Casual Talksがあります！

MySQL Casual Talks in Fukuoka vol.7 - connpass

WEB関連で実際にMySQLを使っている人たちがここを上手くやった！これにハマった！なんてことを紹介してくれることが多いので学びの宝庫

セッションはLTからロングまで時間は自己申告制、ほとんどが公募です

( ´-｀).oO（最近、東京で開催されていないことに気が付いた）

飲みながらしゃべる、飲みながら聞く人が多いです

通称カジュアルウォーター

Club MySQL

日本MySQLユーザ会の副代表、 @sakaik さんによるスピンアウト勉強会です

Club MySQL は、ひとりの講演者の話をじっくりと聞こう、という趣向の、日本MySQLユーザ会の新しいイベントシリーズですだそう

2017年10月に始まった新しめの勉強会です

1年足らずで #4 まで企画されているのでかなり活発ですね

Club MySQL #4 ～周辺知識から理解するMySQL のGIS機能 - connpass

90分くらいのメインセッションと、メインセッションに合わせたテーマでLTが公募されます

ひとりの話をじっくり聞くので、その分野への造詣が深くなりそう

その分、参加者は選ぶのかなあ、という感じもします

そんなClub MySQLの #3 では、わたし yoku0825 とMySQLの出会いとかどこが気に入ってるのかとかどうやってmysqldと仲良くなるのかとか、そんな割とエモい話をする予定です（坂井さんとの通称が yokuさんポエム会）

ご都合が合えば、是非ご来場くださいm(＿＿)m

LTも募集しています！今回のテーマは…あれ

LTの希望者を募集します。今回はちょっと難しいですが「yoku0825さん」に関するテーマでお願いします。 LTは約5分程度で。

https://clubmysql.connpass.com/event/96388/

( д ) ﾟﾟ

#mysql

0 notes

gmomedia-engineer · 6 years

Text

chownには「:」を使うか、「.」を使うかでアンケートを取ってみた話

技術推進室の木村です。

最近暑い日が続くので、重めの話ではなく軽めな話をします。皆さんchownは使っているでしょうか？

chownコマンドはCHange file OWNer and groupの略でchownですが、ファイルの所有権を変更する際に利用することがしばしばあります。

さてこのコマンドですが、以下の様に使うことが出来ます。

$ chown ユーザ名[.|:]グループ名ファイル名

ユーザ名とグループ名で指定する方法が「.(ピリオド)」と「:(コロン)」2つあるんですね。

ということで2つあるなら、どっちの方が利用者が多いのか気になりますよね？ということで社内でサクッとslack上でアンケート取ってみました。

結果は以下の通りで弊社では、大体半分半分くらいでした。

正直私は「:」で覚えてしまっていて「.」が使えることを知らなかったので驚いたのですが、コマンドにも歴史ありということで一筋縄ではいかないものですね。

さて、弊社で半々でしたが、皆さんはどちらを使うことが多いでしょうか？ブコメやTwitterなどで呟いて教えてもらえると嬉しいです。

1 note · View note

gmomedia-engineer · 6 years

Text

TerraformのModuleソースとしてTerraform Enterprise's Private Module Registryを利用する

技術推進室とサービス開発部兼務の宇津井です。前回、前々回から連続してTerraformネタです。

Terraformを利用していると、Moduleの利用は避けて通れないですよね。そのModuleの管理方法は大きく別けても以下の７つが存在します。

https://www.terraform.io/docs/modules/sources.html

Local file paths

Terraform Registry

GitHub

Bitbucket

Generic Git, Mercurial repositories

HTTP URLs

S3 buckets

GMOメディアではこれまでLocal file pathsを利用してきました。Terraform RegistryとGitHub共に実質的には全公開状態でしか運用できなかったためです。

最近になって、Terraform Registryに内包される形？でPrivate Module Registryという選択肢ができました。 GitHubに対してはリポジトリへのアクセスキーをTFEに登録できるようになったため、プライベートなリポジトリでもアクセス権をコード上に記載する事なく運用できるようになりました。これは前回の記事で触れています。

今回はPrivate Module Registryの利用方法だったり特徴をまとめてみます。

主にGitHub管理に対するPrivate Module Registryの利点

Private Module Registryと言っても、ソース管理には何らかのVCSを利用することになります。ここではGitHubでのModule管理に対するPrivate Module Registryの利点をあげてみようと思います。

バージョニングが利用できる

これに尽きると思います。 Module開発を行っていると、どうしても後方互換性が取れない修正だったり、実行結果に変更が生まれてしまう修正が発生します。 GitHubでのModule管理を利用する方法だと常に最新Moduleを利用せざるを得ません。 GitHubにはバージョン機能あるのに！！と思いますが、ないものはない。 terraformのリポジトリでもissueあがってますが、registry使えと言い切られている状況です。

Private Module Registryにはバージョニングの考え方があるので、もし最新バージョンの修正を受け入れたくない場合は以下のようにバージョンを指定することで利用する側でコントロール��できます。

module "vpc" { source = "app.terraform.io/<organization_name>/cf/aws" version = "0.9.3" }

PublicのTerraform Registryを利用しているとよく遭遇しますが、運用をしているとどうしても受け入れたくない変更が発生する場合があります。例えば以下のような状況とか。

dev環境を0.9.3で作り終わった

一通り試験も終わったので、prodを作成しようとしたらModuleバージョンが1.0.0に変わった

メジャーバージョンが上がっていることもあり、出来上がる構成が変わってしまった。

セキュリティの問題があるわけでもないので、0.9.3でprod環境作りたい

Terraform Enterprise Private Module Registryを利用して入れば、上述のコードのようにversionを指定することで、上記のような状況でも、dev環境と同じものが構築できます。この時GitHubでのModule管理を利用する方法を採用してると詰んでしまうのです。（古いバージョンのスナップショットをlocalにコピーするという方法はありますが・・・嫌です）

Privateのポータルサイトが構築される

Private Moduleを登録すると自動で https://registry.terraform.io/ のようなサイトが構築されます。

どんなモジュールがあるのか、GitHubのリポジトリを探して回るのも辛い（専用のアカウントがあるとかなら別ですが）ので一覧性もあり検索もできるポータルが利用できるのは意外に嬉しいかもしれません。

綺麗に見せるにはREADMEとかvariableのdiscriptionを頑張って記載する必要があります。この辺りは色々トライしていこうと思います。

主にGitHub管理に対するPrivate Module Registryの欠点

Private Module Registryは１モジュールに対してVCSを１リポジトリ必要とします。その所以で以下のような欠点があります。

リポジトリの管理が煩雑

GMOメディアにあるモジュール数は現在26個あります。これらに対して、新たにリポジトリを作成して別々に管理していく必要があります。新たにモジュールが必要になった時に一々リポジトリ作成していくのはちょっと重厚な感じがしますね。

料金が高くなる？

新しい料金プランを利用している場合はユーザ数課金で、リポジトリ数は無制限なので問題にならないです。

GMOメディアはGitHubの旧プランを利用しています。旧プランはリポジトリ数に応じて月額の料金が変わっていきますので負担が増加します。

やり方

Private Registry登録方法(GitHubを利用した場合)

Private Registryを利用するにはBitBucket Serverか、GitHub、GitHub Enterpriseのリポジトリが必要です。ここではGitHubを利用したPrivate Registry登録方法を記載します。

リポジトリ作成

VCSのリポジトリ名に以下のような命名規則があるので注意が必要です。

terraform-<provider>-<name>

今回はAWS CloudFront用のリポジトリを用意してみましょう。このような名前のリポジトリを作成します。（GMOメディアではGitHubのリポジトリもTerraformで管理しているので、この名前でPull Requestを送る形になります）

terraform-aws-cf

リポジトリの作成が済んだら、TFEとの連携に使用しているGitHubユーザーにAdminのアクセス権をつけておきます。

Module作成

リポジトリの中身は標準的なモジュール構成に準拠する必要があります。難しそうに見えますが、最小構成はこんな感じですのであまり障害にならないと思います。

$ tree minimal-module/ . ├── README.md ├── main.tf ├── variables.tf ├── outputs.tf

サブモジュール(./modules/)だったり利用例(./examples/)を盛り込む場合はこんな感じ。

$ tree complete-module/ . ├── README.md ├── main.tf ├── variables.tf ├── outputs.tf ├── ... ├── modules/ │ ├── nestedA/ │ │ ├── README.md │ │ ├── variables.tf │ │ ├── main.tf │ │ ├── outputs.tf │ ├── nestedB/ │ ├── .../ ├── examples/ │ ├── exampleA/ │ │ ├── main.tf │ ├── exampleB/ │ ├── .../

例としては記載しましたが、GMOメディアではサブモジュールを利用していませんし、READMEも結構いい加減です。 Private Registryは身内だけが利用するのでREADMEの書き方、コメントの入れ方、コードフォーマット等、利用者のサジ加減で調節可能です。

リリースタグ作成

Moduleの作成が完了したらGitHubでリリース番号を振りましょう。 https://help.github.com/articles/creating-releases/

今回はv1.0.0を作成しておきます。なお、この番号の命名にも規則があって、具体的には v1.0.4 か 0.9.3 というタグである必要があります。いわゆるSemantic Versioningってやつです。

Private Module RegistryにModuleを登録

ここまできたらいよいよPrivate Module RegistryにModuleを登録できます。 https://www.terraform.io/docs/enterprise/registry/publish.html

ここでGitHub側にリリースタグがないとエラーになります。

Private Registry利用方法

CLI Configuration File(.terraformrc)の用意

認証情報を記載した .terraformrc というファイルを用意します。中身はこんな感じで、$HOME_DIRに置いてください。

credentials "app.terraform.io" { token = "xxxxxx.atlasv1.zzzzzzzzzzzzz" }

tokenはpersonal API tokenで取得できるものを指定します。

Private Repositroyを利用したコード

冒頭にも書きましたが、こんな感じです。利用するModuleのProvision Instructions欄にも表示されています。

module "vpc" { source = "app.terraform.io/<organization_name>/cf/aws" version = "1.0.0" }

例としてversionを指定していますが、versionは有っても無くて��構いません。基本的には必要な時だけ記載する方が良いと思います。

所感

やはりリポジトリとか設定ファイルを用意するのとかがちょっと面倒です。でも、バージョンが使えるメリットは絶大なので、悩みどころですね。

GMOメディアではコード管理上GitHubの利用は必須で、バージョニングの機能を必要としていたので、モジュールの管理方法としてPrivate Module Registryを利用することを決定し、徐々に移行しています。

当社での採用事例がHashiCorpさんのブログにも掲載されていますので、是非そちらもご覧ください。

G

0 notes

gmomedia-engineer · 7 years

Text

TerraformのModuleソースとしてGitHubのPrivate Repositoriesを利用する

技術推進室とサービス開発部兼務の宇津井です。前回から連続してTerraformネタです。

Terraform Enterprise（以下TFE)が新しいバージョンになって、TerraformのModuleソースとしてGitHubプライベートリポジトリを利用することができるようになりました。 https://www.terraform.io/docs/modules/sources.html#github

なお、以前でも利用はできたのですが、以下の方法しかありませんでした。

認証情報をソースファイルに書く

パブリックリポジトリを利用する

TFEが新しいバージョンになって色々と調べている中で、SSH KEYを登録して、外部からmoduleをcloneする機能がついたことで世界が変わりました。

なお、TFEにはPrivate Module Registryを利用する方法もあり、こちらでも似たようなことが実現できます。

https://www.terraform.io/docs/enterprise/registry/index.html

こちらについては次回記載してみようと思います。

やり方

Private Repositories登録方法(GitHubを利用した場合)

登録方法といっても難しいことはなく、GitHubにリポジトリ作って中身用意するだけです。 GMOメディアでは以下のようなディレクトリ構造になっています。

$ tree -d . . ├── compute │ ├── ec2 │ └── security_group ├── database │ └── rds │ └── aurora ├── mail │ └── ses-sending-and-recieving ├── network │ ├── alb │ │ ├── alb │ │ ├── alb_listener │ │ └── alb_target_group │ ├── cf │ │ ├── cf │ │ ├── cf-additional-1-cache-behaivior │ │ ├── cf-additional-2-cache-behaivior │ │ ├── cf-additional-3-cache-behaivior │ │ ├── cf-additional-4-cache-behaivior │ │ └── cf-additional-9-cache-behaivior │ ├── dns │ │ ├── route53 │ │ └── route53-alias │ ├── eip │ └── nlb │ ├── nlb │ ├── nlb_listener │ ├── nlb_target_group │ └── nlb_target_group_attachment ├── security │ ├── iam_role │ └── iam_user └── storage ├── elasticache-memcached └── s3

Private Repositories利用方法(GitHubを利用した場合)

SSH Keyを登録

まず、TFE上でGitHubのリポジトリをCloneする必要があるので、SSH KeyをTFE, GitHub双方に登録します。

TFE - Organization setting - Manage SSH Keys

https://www.terraform.io/docs/enterprise/workspaces/ssh-keys.html

GitHub - Personal settings - SSH and GPG keys

https://github.com/settings/keys

SSH Keyとmoduleをcloneする設定

TFEに作成済みのWorkspaceに対して、GitHubからModulesをLocalにCloneする設定を実施します。

TFE - Workspaces - Integrations

設定は２箇所のみです。 SSH KEYには先ほど登録した鍵を指定します。

更に、Include submodules on cloneにチェックを入れて上記の鍵を利用して、GitHubからModulesをコピーする設定を有効にします。

ModuleのSourceをGitHubに向ける

moduleのsourceをlocalからGitHub Private Repositryに向けます。 https://www.terraform.io/docs/modules/sources.html

before

module "consul" { source = "./consul" }

after

module "consul" { source = "[email protected]:hashicorp/example.git//subdir" }

確認

モジュールの中身が一致して入れば以上で終了です。 terraform plan コマンドを打って差分が出ないことを確認しましょう。

所感

これまではモジュールを利用してるとは言いつつ、コピーして使いまわしていたので、Aというサービスで必要になった修正を施しても、Bというサービスの方ではその恩恵を得られないと言った状況でした。

この方法ですと共通モジュール化されたことにより、全てのサービスでその恩恵を得られることになります。

逆に影響範囲が一気に増えるので怖さもあります。Terraformにはバージョンを指定してModuleを利用する機能があるため、この機能を利用すればある程度柔軟に運用できると思いますが、なんとこの機能はTerraform RegistryかTerraform Enterprise's private module registryでしか利用できないらしいです。

https://www.terraform.io/docs/modules/usage.html

Version constraints are supported only for modules installed from a module registry, such as the Terraform Registry or Terraform Enterprise's private module registry. Other module sources can provide their own versioning mechanisms within the source string itself, or might not support versions at all. In particular, modules sourced from local file paths do not support version; since they're loaded from the same source repository, they always share the same version as their caller.

issueに上がってますが言い切っていますね。

versioning is integrated with the module registry

やはりTerraform Enterprise's private module registryを利用した方が良さそうです。ということで、次回はTerraform Enterprise's private module registryの利用方法です。

#terraform

0 notes

gmomedia-engineer · 7 years

Text

Terraform EnterpriseのUpgradeというかMigration方法

暫く投稿をサボっていました。技術推進室とサービス開発部兼務の宇津井です。。

当社では昨年11月頃にTerraform Enterpriseを契約しました。契約後割と早い段階でWorkplaceとかβ版という表記が現れるようになり、それに関してはしっかりとスルーしてたのですが、いつのまにか(正式には2017/12/12)利用していたTerraform EnterpriseにはLegacyという名前がつき、上記のβ版が正式版としてリリースされました。

これを受け、最近では下記のようなメッセージが表示されるようになりました。。

The Packer, Artifact Registry and Terraform Enterprise (Legacy) features of Atlas will no longer be actively developed or maintained and will be fully decommissioned on Friday, March 30, 2018. Please see our guide on building immutable infrastructure with Packer on CI/CD for ideas on implementing Packer and Artifact Registry features yourself and the Upgrading From Terraform Enterprise (Legacy) guide to migrate to the new Terraform Enterprise.

契約した途端に新サービスへの移行を余儀無くされるのは辛いですが、これは迎合するしかない。

ってことで、やり方です。

基本的には下記のアップグレードガイドにある通りですが、当社で実行中の手順を記載しておきます。 https://www.terraform.io/docs/enterprise/upgrade/index.html

これ、Hashicorpはアップグレードって言ってますけど、完全に別システムへの移行という印象が強いです。

作業環境

今回の環境はざっくりこのようなディレクトリ構造になっています。

Hoge.Terraform/ ├── dev ├── modules │ ├── compute │ │ ├── ec2 │ │ └── security_group │ ├── network │ ︙ │ └── storage └── prod

作業内容

大まかにはこういう流れ。stateファイルを新環境に持っていくのが山場。

1. Organization作る 2. ATLAS_TOKEN作る 3. Team作る 4. Workspace作る 5. stateファイル移行　5a. Legacy環境でterraform init 　5b. main.tfのbackendを新環境に適応した内容に変更する　5c. 新環境でterraform init 6. GithubのBranch保護設定を変更 7. githubへ新しい構成をpush 8. Legacyのenvironmentを削除

Organization作る

new-tfeというOrganizationを作ります。（もちろん例です、任意の組織名を使ってください、当社では社名っぽいものを設定しています）

ATLAS_TOKEN作る

各個人のアカウントでATLAS_TOKENが作れるので各々作成して、Token内容を適切に管理・保持します。 https://atlas.hashicorp.com/app/settings/tokens

Team作る

GMOメディアではサービス媒体（システム）ごとにTeamを作成しています。アクセス権の管理はこのTeamの単位で行うので、各ユーザは関連するチームに所属する事になります。

Workspace作る

新規作成

Variables

Access

Integrations

SSH KEYとInclude submodules on cloneは今回の構成だとつけなくてもいいのですが、将来を見越して有効にしています。

Legacy環境でterraform init

この時のbackendの設定内容(hoge-prod環境の例)

terraform { backend "atlas" { name = "old-tfe/hoge-prod" } }

stateファイルを最新にするためterraform initコマンドを叩きます。

git pull cd dev terraform init terraform plan cd ../prod terraform init terraform plan

terraform planの結果がNo changes. Infrastructure is up-to-date. であることを必ず確認してください。

main.tfのbackendを新環境に適応した内容に変更する

terraform { backend "atlas" { name = "new-tfe/Hoge-Prod" } }

Organizationがnew-tfeに変わってます。また、Workspace名がCase Sensitiveになるので注意してください。

新環境でterraform init

cd ../dev terraform init terraform plan cd ../prod terraform init terraform plan

この時にstate fileをインポートするか聞かれるので、yesを入力すること。（これが一番大事）

Do you want to copy existing state to the new backend? Pre-existing state was found while migrating the previous "atlas" backend to the newly configured "atlas" backend. No existing state was found in the newly configured "atlas" backend. Do you want to copy this state to the new "atlas" backend? Enter "yes" to copy and "no" to start with an empty state. Enter a value: yes

stateファイルがコピーされているので、この状態でterraform planを行なっても相変わらずNo changes. Infrastructure is up-to-date. であることを必ず確認してください。

githubへ新しい構成をpush & masterへマージ

PR送る等して、masterブランチへマージしてください。

Run

この状態でplanをキューイングします。ここでも相変わらずNo changes. Infrastructure is up-to-date. であることを必ず確認してください。

GithubのBranch保護設定を変更

masterブランチはプルリク発生時にステータスチェックが入るように設定しているので、これを新環境のTFEへ変更します。

Legacyのenvironmentを削除

旧環境は用済みなので削除しましょう。これを残しておくと、PR時のステータスチェックや、masterブランチへのマージ時に自動でterraform planが実行され続けてしまいます。

その他

module利用の可能性が拡大

このバージョンからかどうか定かではないのですが、module利用の可能性が大きく広がりました。

API

β版のAPIがあるんですが、更新系がまともに動きません。 https://www.terraform.io/docs/enterprise/api/index.html

データ取得(LIST)については、Documentに記載がなくても動いたりもします。

TeamはAPIを利用して作りましたが、Workspaceは500 Internal Server Errorとなってしまいましたので、手作業確定です。（時が経てば直るかもしれませんが）

以上です。最初は移行しなきゃならんのか、辛い。という感じでしたけど、実際に移行してみるといくつかのメリットを享受できたので、それらに関しては次回以降書き続けてみようと思います。（連載宣言）

#terraform

0 notes

gmomedia-engineer · 7 years

Text

Chromeで計測可能になったCSSカバレッジについての調査検証を行ったお話

こんにちは、最近GoogleHomeとビットコインにハマっているミーハーデザイナーの大西です。

今回は、Chrome59でCSSとJSのカバレッジを取得できるようになったので、自社媒体で運用可能かどうかCSSカバレッジの調査と検証を行ってみたいと思います。

そもそもカバレッジとは？

所定の網羅条件がテストによってどれだけ実行されたかを割合で表したものです。出典：カバレッジ(網羅率)分析とは | ソフトウェアの検証の種類 | テクマトリックス株式会社

つまり、CSSカバレッジとはCSSの網羅率ということになります。

カバレッジをあげると何が良いのか？

余分なものを含まなければ、ダウンロードの時間が短くなり（ページの軽量化）、おのずと表示速度が早くなるはずなので、結果的にユーザー体験の向上をはかることが可能であると言えます。（なんと素晴らしい！）

カバレッジツールの利用方法

というわけで、実際にChromeでのCSSカバレッジの計測方法を説明していきたいと思います。

1. カバレッジ項目の追加方法

まず、ChromeのDevToolsを開きます。次に、パネル(Consoleなどがある)のところで、Macであれば command + shift + P で、入力ボックスを表示してShow Coverageを入力して選択します。

すると、Coverageが以下のように追加されていることがわかります。これでカバレッジ計測が可能になりました。

2. Coverageパネルの見方

URL

現在開いているページで使われているCSSとJSのURLが表示されています。

Type

CSSかJSか、ファイルのタイプ。

Total Bytes

ファイルのバイト数です。

Unused Bytes

使われていないファイルバイト数です。（つまり%は使われていない率）

赤と緑のゲージ

赤箇所 = CSS/JSを使用していないもの緑箇所 = CSS/JSを使用しているもの

（検証前）CSSカバレッジの最適な数値とは

では、上記で計測できるページにおける最適な数値はいくつなのでしょうか？

正直よくわかりません。。。（心の優しい方教えてください）もちろん、CSS使用率が100%に近いほどきっと良いはずです。（無駄なものがなくなるからね！）ただ、共通のCSSを読み込んで、追加で独自にCSSを読み込んでいるような媒体などは、使用していないコードが発生すると思います。（リセット系のCSS読み込んでいる、Font Awesome読み込んでいるなどページで使うものは異なるので）実際に弊社の媒体でもカバレッジ計測してみましたが、やはり全て50%にも達していませんでしたorz

調査で得た課題・問題点

今回調査で得た、弊社媒体における課題・問題点が下記になります。

クリック時の使用するもの

モーダル

お気に入り

ドロワーメニューなど

何かしらのフラグがついたときに使用

エラーメッセージ

キャンペーン中などのイベント

入力済み、参加済み

上記は現代のWEBサイトでは普通に搭載されているものだと思いますので、悩ましい課題です。

検証

では調査で得た問題点などを考慮、念頭においてサンプルHTMLを使って検証を行いたいと思います。

読み込み速度

容量

Googleからの評価（正しいHTML構造になっているか、ユーザー体験が悪いようなものを入れていないかなど）

を検証項目として、以下パターンを含むHTMLを用いた検証を行い、上記項目における考察をそれぞれしていきます。

サンプルHTML

使わないCSS、JSを含む（コメントアウトなし）

コメントアウトのコードを含む

clickイベントで動くJSを含む

loadイベントで動くJSを含む

https://gist.github.com/garo1221/6dcc486c9abbc398b8cfa5030fa5b650

読み込み速度

イベントトリガーがあるものは表示されないので、読み込みが早くなる

HTMLでデフォルトで隠しているものなども表示されないので読み込みが早い

容量

（使わないCSSなどを含む）と（CSSなどを全て使う）の比較呼び出し元のコードなどが増えるため（使わないCSSなどを含む）ものの方が容量が小さい。

Googleからの評価（正しいHTML構造になっているか、ユーザー体験が悪いようなものを入れていないかなど）

特に影響、問題は現れていなそうです。 CSSやJSなどを使いテキストを隠すなどを減らしていなければ、SEO的には良いとは言えそうです。（最近のロボットはJSなどをきちんと検知するらしい・・・clickイベントは無視するがloadイベントは理解できるんですって。)

（検証後）CSSカバレッジの最適な数値とは

結論としては、ページ構成によったり、作るデザインの性質によって異なるので、最適解を出すことは現実難しいといえます。なぜなら、エラーメッセージなど最初から隠すことが必要なHTML、それに関わるCSSもカバレッジの対象になってしまうからです。

※すべて使用している状態でも、12.2%使われていないとの表示される。（コード上に赤い部分なし。謎です。。）

現状できる対応

上記、調査と検証を踏まえて現状できそうな対応は、無駄なコードや使っていないコードを削除することになるのかなと思います。（大したことない考察になってしまいごめんなさい。）今後Chromeが上記であげた課題に対してどうアプローチをしていくのか、同行が気になるところです。（頼んだGoogle！）

#css #javascript #covarge #デザイナー

0 notes

gmomedia-engineer · 7 years

Text

プリ画像のサイト表示速度を1msでも改善しようと頑張ったお話

概要

おはようございます。最近すっかり寒くなりましたね…(´ . .̫ . `)秋のすかっとした青空が待ち遠しい。PHPエンジニアの千葉です。

今日は、サーバサイドでサイト表示速度改善を頑張ったお話です。

現在、プリ画像のサイト表示速度は画像一覧画面が約140ms、画像詳細画面は約40msです。

もともとプリ画像の表示速度はとても速かったらしいのですが、去年の夏頃には画像一覧画面で約250〜300msまで悪化していました。

そこで、2016/09〜2016/12にかけて弊社エンジニアの河野と表示速度改善に取り組みました。そのなかで効果の良かったものをまとめたエントリです。

サイト表示速度の推移

下記グラフの赤い線が画像一覧画面のサイト表示速度の推移になります。

クローラーはさまざまな検索ワード・さまざまなページ番号でアクセスしにくるため、キャッシュのないページが見られることが多いです。逆にユーザーの検索ワードは偏りがあるため、キャッシュの恩恵を受けやすく、クローラーほど顕著に数字が変わりません。また、キャッシュ有無だけではなく、検索結果のヒット数でもかなり差が出ます。

クローラーの気分次第で平均値は大きく変わってしまいますが、クローラーに対して速いレスポンスを返せるということは、どんなページでも速くレスポンスを返せることを意味するので、クローラーに対するサイト表示速度を1週間平均120msまで落とすことを目標としていました。横に伸びているオレンジの線が目標ラインです。

青い矢印部分で実施した効果的だった施策3件をこの記事では書いていきます。

※グラフは後半右肩上がりになっていますが、これはまた別の理由に寄るものです。

効果的だった施策

全文検索高速化

リリース日

2016/09/20

効果

リリース前の1時間平均：241ms

リリース後の1時間平均：149ms

概要

検索結果数の多いワードが入っていたり、ページ番号が後ろにいくほど、クエリの実行結果が返ってくるまで非常に時間がかかっていました。

仮に「パンケーキ」が、検索結果数：150万件ヒットするワードだったとします。

mysql> SELECT id FROM xxx WHERE MATCH(xxx) AGAINST('*D+ パンケーキ' IN BOOLEAN MODE) ORDER BY id DESC LIMIT 45,1; +----------+ | id | +----------+ | 61667018 | +----------+ 1 row in set (1.06 sec)

mysql> SELECT id FROM xxx WHERE MATCH(xxx) AGAINST('*D+ パンケーキ' IN BOOLEAN MODE) ORDER BY id DESC LIMIT 1000000,1; +----------+ | id | +----------+ | 20041084 | +----------+ 1 row in set (5.00 sec)

後ろのページに行くほど結果が返ってくるまでの遅さは際立ちます。

MroongaとGroongaのパフォーマンスを比較するために、ベンチマーク（同時接続数10で1000リクエストを投げる）をとった結果、Groongaのほうがパフォーマンスがよく、後ろのページ番号にいくほど、Mroongaとの差は大きくなりました。

検索条件…検索キーワード：パンケーキ、ページ番号：1

パターン①：Mrornga × memcache使用あり

Requests per second: 83.32 [#/sec] (mean) Time per request: 120.016 [ms] (mean) Time per request: 12.002 [ms] (mean, across all concurrent requests)

パターン②：Mroonga × memcache使用なし

Requests per second: 8.74 [#/sec] (mean) Time per request: 1144.067 [ms] (mean) Time per request: 114.407 [ms] (mean, across all concurrent requests)

パターン③：Groonga × memcache使用あり

Requests per second: 81.66 [#/sec] (mean) Time per request: 122.459 [ms] (mean) Time per request: 12.246 [ms] (mean, across all concurrent requests)

パターン④：Groonga × memcache使用なし

Requests per second: 13.84 [#/sec] (mean) Time per request: 722.435 [ms] (mean) Time per request: 72.243 [ms] (mean, across all concurrent requests)

検索条件…検索キーワード：パンケーキ、ページ番号：15000

パターン①：Mroonga × memcache使用あり

Requests per second: 81.55 [#/sec] (mean) Time per request: 122.624 [ms] (mean) Time per request: 12.262 [ms] (mean, across all concurrent requests)

パターン②：Mroonga × memcache使用なし

Requests per second: 4.34 [#/sec] (mean) Time per request: 2302.910 [ms] (mean) Time per request: 230.291 [ms] (mean, across all concurrent requests)

パターン③：Groonga × memcache使用あり

Requests per second: 85.70 [#/sec] (mean) Time per request: 116.691 [ms] (mean) Time per request: 11.669 [ms] (mean, across all concurrent requests)

パターン④：Groonga × memcache使用なし

Requests per second: 13.72 [#/sec] (mean) Time per request: 728.824 [ms] (mean) Time per request: 72.882 [ms] (mean, across all concurrent requests)

これは効果が大きそうだということで、Mroonga→Groongaに変更して、大きく数字を下げることができました。

検索ワードの並び替え

リリース日

2016/12/09

効果

リリース前の1週間平均：150ms

リリース後の1週間平均：118ms

概要

調査を重ねていくうち、検索ワードが複数のフレーズで構成されていた場合、Groongaに渡したときのフレーズの順序がレスポンスに大きく影響があることがわかりました。

例えば、このようなデータがあったとします。

「かわいい背景ねこ」と組み合わせて検索をしてみると、1秒近くもかかってしまっていました。そこで、検索ワード「かわいい背景ねこ」を「かわいい」「背景」「ねこ」の3フレーズに分割します。前もってそれぞれのフレーズに対する検索結果数をMySQLに保存しておき、このデータを使って検索結果数の少ない順番で並び替えてから、Groongaへのクエリを発行するようにしたところ、非常に速く結果が返ってくるようになりました。

検索結果数が多いフレーズで構成された検索ワードのレスポンス速度が大きく改善し、全体の平均を押し下げることができました。

言語ファイル削除

リリース日

2016/01/16

効果

リリース前の1週間平均：117ms

リリース後の1週間平均：115ms

概要

プロファイラをとってみるとZend Frameworkのiniファイル読み込み処理がボトルネックになっていました。不要なiniファイルは言語ファイルくらいでしたが修正量と影響範囲が膨大なため、なかなか削除しきれない状態でした。しかし、ガラケークローズによって修正すべき対象ファイルがぐっと減ったため撲滅することができ、プリ画像全ページが恩恵を受けられました。

iniファイルじゃなくても良いものはロジック側へ移動してiniファイル減らすとさらに抑えられるかもしれません。

おわりに

全文検索高速化の対応後はかなり速くなったので、たった1ms落とすことがものすごく大変でした。

また、画像一覧画面と画像詳細画面における、対クローラーのサイト表示速度はzabbixでいつでも見れるようにしています。( ・ㅂ・)و

#サイト表示速度 #Groonga #php

1 note · View note

gmomedia-engineer · 7 years

Text

MyNA(日本MySQLユーザ会)会 2017年10月を開催しました

ぬいぐるみが好きな方のDBAです。

去る10/23(月)、GMOインターネットグループの運営するシナジーカフェ GMO Yoursにて MyNA(日本MySQLユーザ会)会 2017年10月を開催しました。

MySQL Serverのプロダクトマネージャー Morgan Tocker の来日に合わせて、この日の日中は MySQL最新情報セミナー 2017年10月 in 東京がオラクル青山で開催され、その足でそのまま日本MySQLユーザ会会に駆けつけてくれました。

延べ4時間近くしゃべりっぱなしのもーがんお疲れ様でした。色々楽しい話も聞けました。

わたしのスライドはこちら。

MySQL 8.0で憶えておいてほしいこと from yoku0825

しかし紹介してた新機能とかはいつもとそこまで変わらないような気がするのに、あれだけ盛り上がったのはもーがんの人柄かしらん。日本MySQLユーザ会会ではありませんが、オラクルとしてのセミナーは今週金曜日(10/27)に大阪でも開催されますので、もーがんと握手したい方は是非。 MySQL最新情報セミナー 2017年10月 in 大阪 : ATND

#mysql

0 notes

gmomedia-engineer · 7 years

Text

AWS Network Load Balancer のベンチマークを取ってみた

GMOメディアでエンジニアをやっています河野です。

本日Amazon Web ServicesよりNetwork Load Balancer(以下NLB)の発表がありました。新しいNetwork Load Balancer – 秒間数百万リクエストに簡単にスケーリング

弊社でもいくつかのサービスでAWSを利用しており、Application Load Balancer(以下ALB)やClassic Load Balancer(以下CLB)をバリバリ使っています。

HTTP ProtocolについてはALB、それ以外のTCP通信に関してはCLBという住み分けは出来ていましたが、 CLBはClassicとついている通り今後の積極的な機能拡張はされず、でもTCP通信のLoadBalanceにはCLBを使わざるを得ないという状況でした。

そこで今回のNLBの登場となり、個人的に夢が広がりまくってるところであります。

NLBの説明はAWSの発表資料を見てもらうのが一番だと思いますが、一番期待している所はパフォーマンスについてです。

NLBはいわゆるLayer4(トランスポート層) Load Balancerであり、TCPレベルでのルーティングを行うことで非常にパフォーマンスが良いことで知られています。それに対してALBはいわゆるLayer7(アプリケーション層)であり、HTTP通信そのものを理解してルーティングを行うことで柔軟なルーティング設定が可能ですが、パフォーマンス面ではL4に比べて一歩劣ってしまうのが一般的です。

ではそのパフォーマンスはどれだけ良くなっているのか、ALBとの比較の為にHTTP通信で簡単なベンチマークを取ってみます。

構成は以下のような感じです。

VPCネットワーク内のPublicとPrivate SubnetにEC2インスタンスをAmazon Linuxで立ち上げています。 WEBアプリケーションのベンチマークで使われることの多い Apache Bench(以下ab)と、WEBサーバー側はNginxを使い、 helloと返すだけの小さな静的ページに対してリクエストを投げてみます。

ALB

Server Software: nginx/1.10.3 Server Hostname: internal-kawano-test-alb-576724782.ap-northeast-1.elb.amazonaws.com Server Port: 80 Document Path: /hello.html Document Length: 6 bytes Concurrency Level: 10 Time taken for tests: 0.312 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Total transferred: 235000 bytes HTML transferred: 6000 bytes Requests per second: 3201.83 [#/sec] (mean) Time per request: 3.123 [ms] (mean) Time per request: 0.312 [ms] (mean, across all concurrent requests) Transfer rate: 734.80 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 1 0.5 1 5 Processing: 1 2 0.7 2 7 Waiting: 1 2 0.6 2 6 Total: 2 3 0.9 3 10 Percentage of the requests served within a certain time (ms) 50% 3 66% 3 75% 3 80% 3 90% 4 95% 4 98% 6 99% 8 100% 10 (longest request)

NLB

Server Software: nginx/1.10.3 Server Hostname: kawano-test-nlb-783e4d8f6b9cd0ea.elb.ap-northeast-1.amazonaws.com Server Port: 80 Document Path: /hello.html Document Length: 6 bytes Concurrency Level: 10 Time taken for tests: 0.076 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Total transferred: 235000 bytes HTML transferred: 6000 bytes Requests per second: 13219.64 [#/sec] (mean) Time per request: 0.756 [ms] (mean) Time per request: 0.076 [ms] (mean, across all concurrent requests) Transfer rate: 3033.81 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 1 Processing: 0 0 0.1 0 1 Waiting: 0 0 0.1 0 1 Total: 1 1 0.1 1 1 Percentage of the requests served within a certain time (ms) 50% 1 66% 1 75% 1 80% 1 90% 1 95% 1 98% 1 99% 1 100% 1 (longest request)

IP Address直リクエスト

Server Software: nginx/1.10.3 Server Hostname: 172.31.3.95 Server Port: 80 Document Path: /hello.html Document Length: 6 bytes Concurrency Level: 10 Time taken for tests: 0.070 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Total transferred: 235000 bytes HTML transferred: 6000 bytes Requests per second: 14302.88 [#/sec] (mean) Time per request: 0.699 [ms] (mean) Time per request: 0.070 [ms] (mean, across all concurrent requests) Transfer rate: 3282.40 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 0 Processing: 0 1 0.1 1 1 Waiting: 0 1 0.1 1 1 Total: 0 1 0.1 1 1 Percentage of the requests served within a certain time (ms) 50% 1 66% 1 75% 1 80% 1 90% 1 95% 1 98% 1 99% 1 100% 1 (longest request)

結果

Request per sec Time per request(ms) ALB 3201.83 0.312 NLB 13219.64 0.076 直IP 14302.88 0.070

ALBに対してNLBは3～4倍、IP Address 直アクセスと遜色ないパフォーマンスが出ていることがわかります。

要件次第ではありますが、単純なHTTP通信であり、且つパフォーマンスが要求される箇所や、静的IPが必要ということであればNLBという選択肢も有りなのではないでしょうか。

費用に関しては東京リージョンでNLBは $0.006/GB、ALBは $0.008/GBなので、ALBよりリーズナブルになっています。

ELBに新たな機能が加わったことで今まで以上に柔軟なシステム設計ができるようになると思います。

是非使ってみてください。

#AWS

3 notes · View notes

gmomedia-engineer · 7 years

Text

pt-table-checksumでテーブル名の大文字小文字にハマったはなし

ごきげんよう、GMOメディアにてDBAをやっておりますshowです。今回はタイトルの通り、pt-table-checksumでテーブル名の大文字小文字にハマったはなしをお伝えします。

■そもそもpt-table-checksumとは

pt-table-checksumとは、米国PERCONA社がOSSで提供しているPercona Toolkitに含まれるツールで、MySQLでのレプリケーション環境においてマスターとスレーブ間でのレプリケーションの整合性を確認するツールです。このツールを用いることでマスターとスレーブで、データベース名やテーブル名、テーブル内のデータの整合性がとれているのかどうか等をオンラインで確認することができます。ドキュメントはこちら https://www.percona.com/doc/percona-toolkit/LATEST/pt-table-checksum.html

■ハマった経緯

今回、弊社においてMySQLサーバの引っ越し（移行）＆アップグレード作業がありました。引っ越し対象のMySQLサーバのインスタンスではlower_case_table_namesが無効になっているため、クエリ��おいてテーブル名等の大文字小文字を明確に指定する必要がありました。そこで、新しいMySQLサーバのインスタンスではクエリが大文字でも小文字でも問題なくアクセスできるようにlower_case_table_namesを有効にするという要件がありました。そのため現状のMySQLサーバのインスタンスをインプレースアップグレード（mysql_upgrade）するのではなく、敢えて一旦mysqldumpでデータを抽出し、新しいインスタンスに抽出したデータを挿入するという手法で引っ越しを実施しました。引っ越し先のMySQLサーバのインスタンスにデータの挿入を実施後、引っ越し元のMySQLサーバのインスタンスをマスターとし、引っ越し先のMySQLサーバのインスタンスとレプリケーション環境を構築してデータを同期させました。レプリケーション環境を構築できたのでデータなどの整合性を確かめるためにpt-table-checksumを実行したところ、以下の結果が出力されました。

07-05T13:52:01 Skipping table db.HOGE_TABLE because it has problems on these replicas: Table db.HOGE_TABLE does not exist on replica new-server This can break replication. If you understand the risks, specify --no-check-slave-tables to disable this check. 　　　TS ERRORS DIFFS ROWS CHUNKS SKIPPED TIME TABLE 07-05T13:52:11 0 0 2647818 15 0 10.066 db.fuga_table

スレーブ（引っ越し先）にHOGE_TABLEは存在しない、fuga_tableは存在するしマスタースレーブ間でデータの差分もなしとのことです。 lower_case_table_namesを敢えて変更している、最初から全て小文字だったテーブルはpt-table-checksumが通っていて、マスター（引っ越し元）が大文字のテーブルだけ「存在しない」と判断されていました。今回の引っ越しにおいてlower_case_table_namesの設定を変更したため、テーブル名において引っ越し元では大文字の場合がある一方で、引っ越し先ではすべて小文字に変換されており、HOGE_TABLEではなくhoge_tableが存在しました。しかし、pt-table-checksumでは SHOW TABLES FROM データベース名 LIKE テーブル名; というクエリを用いてテーブルが存在するか確かめます。そこで、テーブル名を大文字にして SHOW TABLES FROM DB LIKE 'HOGE_TABLE'; というテーブル名を大文字にしたクエリを、引っ越し先のテーブル名が小文字であるMySQLで実行したところ、きちんと結果が返ってきました。つまりテーブルは存在すると判断されるはず。それでも「Table db.HOGE_TABLE does not exist on replica new-server」となるのはなぜか。。。

■ソースを読んでみた

同様の事象がないかWebで検索しても一向に見つからなかったため、pt-table-checksumのソースを読んでみました。ソースはこちら https://github.com/percona/percona-toolkit/blob/release-3.0.3/bin/pt-table-checksum すると、本件の該当箇所として

if ( !$row->[0] || $row->[0] ne $tbl ) { 　PTDEBUG && _d('Table does not exist'); 　return 0; }

という条件分岐を見つけました。これは、 SHOW TABLES FROM DB LIKE マスターのテーブル名; というクエリをスレーブ側で実行した結果で「テーブル名を取得しようしたがEmptyだったもしくは取得したテーブル名がマスターのテーブル名と一致しなかったならTable does not existと判断する。」という条件分岐になっておりました。そのため、今回の場合、スレーブ側（引っ越し先）でテーブル名「hoge_table」は取得された（存在した）けれども、マスターのテーブル名「HOGE_TABLE」と文字列として一致しないので、該当のテーブルが存在しないと判断されたことになります。

■ソースを書き換えた

上記の条件分岐の判定となっていたため、if文の条件を

if ( !$row->[0] || $row->[0] ne $tbl )

から

if ( !$row->[0] || lc($row->[0]) ne lc($tbl) )

と書き換えて「テーブル名を小文字に変換して比較することで、比較対象の元々のテーブル名が大文字と小文字で異なる場合でも一致と判断する」と変更しました。

■結果

この変更後にpt-table-checksumを再実行したところ、無事に動作させることができました。

■所感

OSSはソースが公開されているというメリットがあるので今回の対応ができました。ハマった時はWebで検索して調べることも必要ですが、ソースを読んでみる必要性もあると改めて感じた次第です。

#mysql

1 note · View note

gmomedia-engineer · 7 years

Text

GMOテクノロジーブートキャンプで新卒のエンジニアをポカーンとさせてきたはなし

ぬいぐるみが好きな方のDBAです。

GMOグループには4年くらい前から始まった GMOテクノロジーブートキャンプなる新卒エンジニアの一斉研修（とはちょっと違うみたいですが）があります。

その際講師を務めるのは、各分野の第一線で活躍する先輩エンジニア。この研修を通して会社の垣根を越えた師弟関係が誕生することでしょう。

残念ながら今日MySQLの話をしたおじさんは先輩エンジニアというよりズンドコキヨシストレージエンジンとか書いて喜んでいるMySQLジャンキーです。ごめんなさい。

( ´-｀).oO（去年と同じ書き出しにしてみた

GMOテクノロジーブートキャンプでMySQLおじさんしてきた | GMOメディアエンジニアブログ

去年は「明日使えないMySQLの無駄知識」をテーマにMySQLへの愛を語ってきて今年もそれで乗り切ろうかと思っていましたが、今年の新卒の某氏が「2年くらいまえに見たわ」とかプレッシャーをかけてきたので書きおろしの新作（？）と相成りました。

わかった気になるMySQL from yoku0825

わたしはこの手の研修の講師をやる時に心に決めていることがあって、

ちょっとMySQLができるエンジニアも

MySQLなんて触ったことないエンジニアも

等しく全然わからないであろうことを

全力で説明する

というものです。

よく使う構文とかググればいくらでも出てくるし、そんなのやってたら1時間じゃ足りないし、そんなことはどうでもいいから俺が最近10時間くらいかけて読んだSQLパーザーの話を聞いてくれ！という感じです。

師弟関係が誕生したかどうかはNULLですが、「なんかよくわからんがMySQLでぶち当たったらコイツに聞けばいいかな」とか「ジェネラルログにはクエリー書かれてるんだけど、Max Query per Hour に引っかかってるっぽいけどそういうもんだったっけ？」とか思った時に思い出してもらえる存在になれればいいなと思います。

なお毎年恒例（？）のMySQLより年下ネタ、

今年は、いました。 https://t.co/kgCwzTIcjw

— yoku0825 (@yoku0825) 2017年6月23日

#mysql

0 notes

gmomedia-engineer · 7 years

Text

月末に向かってInnodb_rows_readが増えていくグラフのはなし

ぬいぐるみが好きな方のDBAです。

弊社ではMySQLのリソースモニタリングにCactiを利用していますが、こんな形の “InnoDB Row Operations” のグラフを見たことはないでしょうか。月初には低い値を示していたRows Read（水色のエリア）が月末に向かってだんだんだんだん伸びていくグラフです。

そして、月初になるとス㌧と落ちて月末に向かって大きくなっていって…を繰り返します。

よく訓練されたMySQLerのみなさまにはこのグラフを見ただけで原因の想像がつきそうなものだと思いますが、Innodb_rows_readがこのようなグラフの形を描く場合、ほとんどの原因はログテーブルのテーブルスキャンです。

月初はTRUNCATEや新しいテーブル（テーブル名_201705 とかでローテーションしたりするのに心当たりはありませんか？）への切り替え直後なので、テーブルスキャンでも読み取る行の数はたかが知れたものです。

が、ログテーブルですから月末に向かって行数が（大概の場合、線形に）増えていきます。テーブルスキャンですから読み取る行の数はテーブル内の行数と一致するので、上記のようなグラフの形を描くことになるのです。

対象のMySQLが5.6かそれ以降のバージョンで、performance_schemaが有効になっている（そしてsetup_instrumentsをデフォルトから減らしていない）場合、この裏付けはsysスキーマからも取ることができます（5.6の場合sysはバンドルされていないので、こんな感じで自分でSQLステートメントを流し込む必要があります。が、別に全然難しくない）

$ git clone https://github.com/mysql/mysql-sys $ cd mysql-sys $ mysql -uroot -p < sys_56.sql mysql> use sys mysql> SELECT * FROM statements_with_full_table_scans ORDER BY rows_examined DESC; +-------------------------------------------------------------------+-----------+------------+---------------+---------------------+--------------------------+-------------------+-----------+---------------+---------------+-------------------+---------------------+---------------------+----------------------------------+ | query | db | exec_count | total_latency | no_index_used_count | no_good_index_used_count | no_index_used_pct | rows_sent | rows_examined | rows_sent_avg | rows_examined_avg | first_seen | last_seen | digest | +-------------------------------------------------------------------+-----------+------------+---------------+---------------------+--------------------------+-------------------+-----------+---------------+---------------+-------------------+---------------------+---------------------+----------------------------------+ | SELECT COUNT ( `xxx` ) FRO ... `play_date` < ? AND POINT > ? | xxxxx | 114123 | 5.84 h | 114123 | 0 | 100 | 114123 | 51939503092 | 1 | 455119 | 2017-05-24 15:54:49 | 2017-05-31 10:18:45 | 8ceaadf1155dfbb51a1c72d1731c8d61 | | SELECT * FROM `xxx` WHERE `x ... ? ORDER BY `sum` DESC LIMIT ? | xxxxx | 114126 | 4.17 h | 114126 | 0 | 100 | 2282520 | 27113833807 | 20 | 237578 | 2017-05-24 15:54:48 | 2017-05-31 10:18:44 | b085842d2ee51702ba822634909cddaa | | SELECT COUNT ( `xx` ) FROM `xx ... layed_date` < ? AND `sum` > ? | xxxxx | 114123 | 3.69 h | 114123 | 0 | 100 | 114123 | 27110838548 | 1 | 237558 | 2017-05-24 15:54:49 | 2017-05-31 10:18:44 | d626b47a3c3d5bfad1ff85126e19ec3a | ...

��エリーのテキストが勝手に切り詰められる（FROM句のテーブル名が見えない）件は、SELECTするビューを “statements_with_full_table_scans” から “x$statements_with_full_table_scans“ に変更するとテーブル名などまでちゃんと見えます。

ほうらね！さあ、インデックスを張る算段をしないとな。

#mysql

1 note · View note

gmomedia-engineer · 8 years

Text

DroidKaigi 2017 にGMOメディアのエンジニアが登壇します

こんにちは、ポイントメディア事業部でAndroidエンジニアをやっております佐藤です。

DroidKaigi 2017というAndroidカンファレンスに弊社から私、佐藤(@syarihu)が登壇します。

DroidKaigiとは

DroidKaigiはエンジニアが主役のAndroidカンファレンスです。Androidの技術情報の共有とコミュニケーションを目的に、2017年3月9日(木)、3月10日(金)の2日間開催します。

Function introduction of Google Play Services @syarihu

2017年03月09日 14:20 - 14:50 Room2で講演します。

このセッションでは、数多くの機能が存在するGoogle Play Servicesの中から3つの機能をピックアップし、実装方法や検証した結果どうだったのかも含めて紹介します。

1つ目は、以前は実装するのが複雑で分かりづらい部分もあったGoogleサインインが、シンプルに実装できるようになった新しいGoogle Sign-In APIについてお話します。

2つ目は、ユーザーが気に入ったコンテンツをGoogle検索でおすすめしたり、Google+で共有することができるGoogle+1ボタンについて、Androidアプリ内に実装することでどのような変化があったのかをお話します。

そして3つ目は、メールやSMSで友人・知人を簡単に紹介することができるApp Invitesと呼ばれる機能について、フローや仕組み、実装することでどんなメリットがあるかなど検証結果も交えてお話します。

個人で11個のアプリを公開した結果 @syarihu

2017年03月10日 11:50 - 12:20 Room 4で講演します。

このセッションでは、佐藤が弊社とは関係なく個人的に開発してきたアプリで得られた知見について紹介します。

個人でAndroidアプリ開発をはじめたきっかけや、開発した11個のアプリについてカテゴリごとにインストール数やレビューなどの実際の数値も交えてお話します。また、開発・公開するためには何が必要なのかやレビューがきたらどうすれば良いのか、使ってみて便利だったツールなど個人で開発する上で困りそうなことをいくつかピックアップしてお話しますので、これから個人開発をしようと思っている方の参考になれば幸いです。

よろしくお願いします！

0 notes

gmomedia-engineer · 8 years

Text

Percona Server 5.6を5.7にアップグレードしようとしてドハマりしたはなし

ぬいぐるみが好きな方のDBAです。

TL;DR

Percona Server 5.6を正常にシャットダウンしたのに

[ERROR] InnoDB: Upgrade after a crash is not supported. This redo log was created before MySQL 5.7.9, and we did not find a valid checkpoint. Please follow the instructions at http://dev.mysql.com/doc/refman/5.7/en/upgrading.html

と言われて5.7のバイナリーで起動できないときは、

innodb_log_block_sizeの指定をコメントアウトして

InnoDBログファイルを消してmysqldを再起動

新しくInnoDBログが作成されて起動してくるので、停止

Percona Server 5.7のバイナリーで起動してmysql_upgrade

Bug #1647728 “innodb_log_block_size breaks in-place PS 5.6 -> 5....” : Bugs : Percona Server

さて本編。みなさんPercona Serverはお好きですか？

ウチは基本的にはVanilla MySQLを使っていますが、

スレッドプールが使いたいとき

HandlerSocketが使いたいとき

はPercona Serverを利用しています（その他のメリットに関しては @mita2 さんの MySQL 互換のDB、Percona Server を使う理由 - Qiita を読むと幸せになれます）

で、Percona Server 5.6なサーバーを5.7にアップグレードしようとしたのですよ。

やり方はインプレース（datadirをそのまま使いまわして、 mysql_upgrade で仕上げるやり方）アップグレードを選んだんですが、これにドハマり。

フツーのインプレースアップグレードといえば、

$ /usr/local/percona56/bin/mysqladmin --defaults-file=.. shutdown $ /usr/local/percona57/bin/mysqld_safe --defaults-file= .. & $ /usr/local/percona57/bin/mysql_upgrade --defaults-file=.. $ /usr/local/percona57/bin/mysqladmin --defaults-file=.. shutdown $ /usr/local/percona57/bin/mysqld_safe --defaults-file= .. &

とまあこんな感じ、5.7のバイナリーで起動してmysql_upgradeをかけてから再起動な訳なんですけれども、

＿人人人人人人人人人人人人人人人人人＿＞　5.7のバイナリーで起動できない　＜￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^￣

( д ) ﾟﾟﾌｧｯ!?

慌ててエラーログを覗いてみると、そこには

[ERROR] InnoDB: Upgrade after a crash is not supported. This redo log was created before MySQL 5.7.9, and we did not find a valid checkpoint. Please follow the instructions at http://dev.mysql.com/doc/refman/5.7/en/upgrading.html

MySQL 5.6 => 5.7の時にも起こるやつで、前のバージョンのmysqldが正常終了していない（=クラッシュリカバリーをかける必要がある）状態だと、5.7のバイナリーで起動できなくなるヤーツ。

え、ちょっと待って5.6正常終了させたよ…？；

Perconaの5.6 => 5.7アップグレードガイドも MySQL 5.7のアップグレードガイドも覗いてみるけれど、「クラッシュリカバリーが必要な状態ではアップグレードできない（あるいは推奨しない）」とは書いてあるけれど、正常終了したのにクラッシュリカバリーを始めようとする理由はどこにも注意書きがない。

:(；ﾞﾟ'ωﾟ'): なにこれ

どこをどうググってたどり着いたのかよく憶えていないんだけれど、innodb_log_block_size (Percona 5.7ではupstreamの innodb_log_write_ahead_size に統合された）を指定している場合、一度その指定を外してデフォルトのinnodb_log_block_sizeでログを作り直さないとクラッシュリカバリーが走ろうとして5.7のバイナリーが起動できないバグらしい。

Bug #1647728 “innodb_log_block_size breaks in-place PS 5.6 -> 5....” : Bugs : Percona Server

ばぐれぽにワークアラウンドが書いてあって助かった。。本当にありがたい。

ちなみにPercona Serverを選ぶ理由だったHandlerSocketは5.7にはポートされてない（SHOW PROCESSLIST見るまで忘れてた。。） PK引きしかやってないらしいので、InnoDB Memcached Pluginで頑張るか、それともSQLに戻るか…。

Changed in Percona Server 5.7

（この記事を書いている日から見て）明日あたりに本番に入るそうです。

#mysql #percona

0 notes

gmomedia-engineer · 8 years

Text

GMOメディアエンジニアブログ 2016年間ランキング

こんばんは、技術推進室の宇津井です。

2016年も残りわずかですが、なんと今年初投稿です(爆)

ハートビーツさんの記事を見てうちのエンジニアブログも年間PVランキング出してみよう！と思いたったので、久しぶりに記事を書いてます。

こちらがPVを基にした年間ランキングです！

1位　16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する

2015年末に寄稿された大作記事です。記事も大作ですが、内容はもっと大作です。

2位　【Unity Asset】iTweenがすごく便利だった

うちのエンジニアブログ、Unityが結構人気です。当初盛り上がったUnity部の活動は現在控えめです。

3位　無償化されたUnityのスマートフォン書き出し機能でお手軽にAndroidゲームを作る方法まとめ

こちらもUnity〜。エースコンバットみたいなのは未だに語り継がれていますが、未だに飛行した話を聞きません。

4位　 Railsの自動テスト(RSpecでModelのテスト編)

弊社のRailsアプリは現在Minitestを採用していますが、これはRSpecを採用していた頃の記事ですね。

5位　 Elasticsearchとkuromojiでちゃんとした日本語全文検索をやるメモ

今やElasticsearchとkuromojiなんて当たり前に感じますが、執筆当時は参考になる日本語記事が少なく未だに検索流入が続いています。

6位　 git pullは、fetchしてmergeするのと同じなのか？

git pull怖くないよ。

7位　 Rails Jbuilderのあまり知られてないかもしれない？メソッド3選

コード読むの大切。読んだ結果を晒すのも大切ですね。

8位　数十台規模のPHP 5.3プロジェクトをダウンタイムゼロでPHP 5.6化した時のまとめ

EOLから抜け出した事例です。 PHP 5.6のEOLも2018/12まで。残り2年ですね。

9位　Redis Sentinelを運用してみたお話

全般的に言えるかもしれませんが、運用した実績を語る記事が人気になりやすく、この記事も実績に基づいた記事ですね。今もこちらの構成を基に若干修正されて運用されています。

10位　iPhone実機でUnityを動かしてみた

その後音ゲーがどうなったのか聞いてませんw

以上、GMOメディア　エンジニアブログの2016年間ランキングでしたー。

皆様よいお年を！

#ランキング

2 notes · View notes