[deep dive]infra寄りのdevがお送りするrds for aurora徹底検証
TRANSCRIPT
![Page 1: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/1.jpg)
Infra寄りのDevがお送りする RDS for Aurora徹底検証“Aurora” is a new amazing RDBS that is not “MySQL”
![Page 2: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/2.jpg)
えっと、誰ですか?Masashi Terui JIG-SAW 札幌オフィス
技術開発グループ リーダー
Twitter: @marcy_terui Github: marcy-terui Facebook: marcy.terui
Dev for Ops的なお仕事 Like→MySQL、Work→Postgres
AWS Certified SysOps,Dev,SA(Associate) Winner of Tuningathon #5 (MySQL)
![Page 3: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/3.jpg)
Limited Preview中につき情報の開示に制限があるため、 煮え切らない表現に感じる部分があるかと思いますが、 何卒ご理解ください。
![Page 4: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/4.jpg)
今までのMySQLとの違いにフォーカスし、 仮説と検証を元に、インフラ寄りの開発者の目線から Auroraを実戦で使うためのヒントをお伝えできればと思います。
![Page 5: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/5.jpg)
AgendaAuroraってこんなにすごい!
Auroraに対する評判(一部)
Auroraの特徴からInfra寄りなDev視点で見る着目点
Auroraで変わる運用
Auroraへの移行方法
まとめと感想
![Page 6: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/6.jpg)
Auroraってこんなにすごい!MySQLより5倍速い
高い耐障害性
商用エンタープライズDBより遥かに安い価格で同等の機能
クラウドのためにRDBMSを再設計
MySQL 5.6.10互換
etc…
![Page 7: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/7.jpg)
Auroraに対する評判(一部)
革新的
これぞ、クラウド時代のデータベース
うまい、はやい、やすい
MySQLはOracleに買収されて先が不安だから乗り換えたい
MySQLはもう要らない子?
![Page 8: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/8.jpg)
それで本当に良いの?
![Page 9: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/9.jpg)
全くトレードオフのないアーキテクチャなど存在しない
SSD, scale-out, multi-tenant storage
Quorum
Log structured storage
Service Oriented Architecture
![Page 10: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/10.jpg)
開発元のベンチマーク結果を鵜呑みにしてはいけない
AWS, Auroraに限らず
例:RDS 30kPIOPSがi2.8xlargeのローカルSSDより書き込みが速いなんて、ちゃんとチューニングしてないのでは?http://www.slideshare.net/AmazonWebServices/sdd415-new-launch-amazon-aurora-amazons-new-relational-database-engine-aws-reinvent-2014/21
とはいえ、Auroraが速いことを否定するものではない
自分の要件にあっているかは自分で測る
![Page 11: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/11.jpg)
Oracle買収後のMySQLの動向を知らないのでは?Oracleが買収時に約束した保証期間の5年が過ぎ、どうなったか?http://www.itmedia.co.jp/enterprise/articles/0912/14/news083.html
Sun時代よりはるかにリソース投入してるし、進化してるhttp://japan.zdnet.com/article/35056719/
じゃあ、Amazonは?
• 圧倒的なAWSの進化スピード
• 今までに廃止したサービスは「0」
Amazonを取るか、Oracleを取るか、、、で決めちゃって良いの?
![Page 12: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/12.jpg)
じゃあ、何を使えば良いのさ!?
![Page 13: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/13.jpg)
Auroraが素晴らしいのは間違いないです。
でも、何にでも使える夢のデータベースではきっとありません。
自分の用途にあう方を使いましょう。
お互いの特徴を知り、目的にあったものを使うべき。
そのためのヒントになれば幸いです。
![Page 14: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/14.jpg)
Auroraの特徴から Infra寄りなDev視点で見る着目点
![Page 15: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/15.jpg)
の前にちょっと横道
![Page 16: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/16.jpg)
AuroraはMySQL Serverよりも、 MySQL Clusterに似ているのではないか?表向きはMySQLだけど、バックエンドが違うという点
MySQL Clusterはフラグメントと同期レプリケーションを組み合わせたシェアードナッシングアーキテクチャ
AuroraはQuorumで信頼性を担保し、分割による複雑性を排除しつつデータノードのみ多重化している感じ
極限までスケールするのはMySQL Cluster
ただし、大半のアプリケーションそこまで必要ではないので、運用面等も考えるとAuroraは非常に良い所を突いている感じがする
![Page 17: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/17.jpg)
MySQL5.7についてもうそろそろRC(リリース候補版)が出そう?
Auroraは現状、5.6互換
Auroraは追従するのか、独自の機能に注力するのか?
個人的にはオプティマイザやパーサーの改善など、コアの部分は取り込んで欲しい
しかし、FTS、GIS等の機能面は別の道に注力して欲しい
![Page 18: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/18.jpg)
Auroraの特徴から Infra寄りなDev視点で見る着目点
![Page 19: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/19.jpg)
Cache
![Page 20: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/20.jpg)
InnoDB Buffer Pool
一番大事なやつ
Auroraのストレージが速かろうと(万が一遅かろうと)ここに載っているデータを見ている場合はきっとあまり変わらない
Readはここに載っていれば速いのとRead Replicaでスケールできるというのもあり、Writeのスループット向上に注力している感もある
![Page 21: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/21.jpg)
Query Cache
AuroraはデフォルトON (RDS for MySQL及びセルフインストール時のデフォルトはOFF)
キャッシュのチェックと更新のオーバヘッドがバカにならないので、多くのケースのOLTPではOFFにした方が良いと言われている
最適化されているのかもしれないが、本当にONのままで良いのか?
![Page 22: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/22.jpg)
Storage
![Page 23: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/23.jpg)
ざっくり補足①:Quorum
http://yoshidashingo.hatenablog.com/entry/2014/11/26/032121
4本の書込みQuorum
残りは非同期で反映
3本の読込みQuorum
3本でデータが揃えば正と言える
DynamoDB等でも使われている
![Page 24: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/24.jpg)
ざっくり補足②:Log structured storage
http://www2.cs.uh.edu/~paris/7360/PowerPoint/LFS3.ppt
ファイルシステムそのものをログのように扱う
書き込みは常に追記
ファイルとそれにまつわるメタデータがまとめて書き出せる
過去データがそのまま取り出せる
![Page 25: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/25.jpg)
SelectFull/Big Scan
ストレージが全く別物なので、これに関しては同じということはまず無い
Log structured storageはデータが連続した領域に書き込まれるため、シーケンシャルアクセスに強そうだが…?
巨大なデータセットをQuorumで多数決するオーバヘッドは?
データがノードを跨がないので、MySQL Clusterみたいに細かなScanが遅いとかはなさそう
最大64TBのデータが入るっていっても、スキャンはできないと思ったほうが良いんだよね?
Random Select
SSD最適化による高速化に期待
![Page 26: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/26.jpg)
Write
ベンチマークが示す通り、速いはず
特にUPDATEやDELETEのコストがLog structured storageの恩恵で大きく下がっていると思われる(あらゆる更新が追記となるためINSERT並のコストになるはず)
![Page 27: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/27.jpg)
Temporary Table
所謂、クソクエリ(だけとは限らないが)に対する性能
Log structuredである必要がない
問い合わせを受けたノードだけが必要で共有する必要もない
![Page 28: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/28.jpg)
Other cores
![Page 29: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/29.jpg)
Parser, Optimizer etc…
このあたりはおそらく一緒
クソクエリはAuroraでもクソクエリだろうから書き直せ(#゚Д゚)ゴルァ!!
後で聞いた話ですが、変わっているそうです。要検証!
![Page 30: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/30.jpg)
Auroraが変える運用
![Page 31: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/31.jpg)
Backup and Recovery
![Page 32: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/32.jpg)
Before
従来は、定期フルバックアップ+差分バイナリログバックアップ
復旧は直近のフルバックアップをリストアした上で、差分バイナリログによる更新を順次適用
フルバックアップからの更新量に比例して復旧時間が長くなる
RDSなら定期・フルどちらもS3に待避されるため信頼性は非常に高い
![Page 33: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/33.jpg)
After Aurora
過去のデータ全体がそのままの状態で取り出せる
差分適用が無い分、間違いなく高速
かつ、それを継続的にS3へ待避しているため信頼性も抜群
![Page 34: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/34.jpg)
Read Replica
![Page 35: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/35.jpg)
Before
従来は、Masterから受け取ったバイナリログの更新内容をSlaveで同じように適用する
つまり、外から見るとRead Onlyだが、内部的にはガリガリ更新が走っている
SQL(更新を適用する)スレッドがMasterからの更新ログについていけず、遅延することも多い(特に5.6以前はシングルスレッドだったので顕著)
![Page 36: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/36.jpg)
After Aurora
AuroraはMasterとSlaveで同じデータを見ているため、更新処理が必要ない
つまり、100% Readのためだけに性能をフルに使える
ある意味当然だが、基本的にラグがない
Replicaを増やす場合にもデータコピーやログ適用の必要がない
![Page 37: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/37.jpg)
Scaling
![Page 38: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/38.jpg)
Before
まずはスケールアップ
読み込みはRead Replicaでスケール可能
書き込みはShardingするしかない
容量追加はディスク増設 or Sharding
![Page 39: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/39.jpg)
After Aurora
読み込みスケールがRead Replicaなのは一緒だが、Replicaの作成コストが低い(前述)
書き込みはノードとしては1つであるものの、裏のストレージがスケールするので青天井ではないもの期待はできる
ディスク容量は自動でスケール(使った分だけ支払い)
![Page 40: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/40.jpg)
Failover
![Page 41: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/41.jpg)
BeforeRDSではない場合はRead Replicaを組んで、mysqlfailoverやMHAが一般的
対象が非同期レプリケーションだとデータ損失の可能性有り(凖同期でも100%ではない)
RDSの場合、Multi-AZスタンバイへのレプリケーションは、独自の仕組みにより完全同期となっており基本的に損失はない
ただし、Multi-AZスタンバイはRead Replicaとしては使えない
![Page 42: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/42.jpg)
After Aurora
対象はRead Replicaのいずれか
ストレージは同じものであるためデータ損失無し
スタンバイ分の料金が浮く
![Page 43: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/43.jpg)
Simulate Failures
![Page 44: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/44.jpg)
Before
基本的に難しい
シャットダウンとクラッシュは違う
想定した復旧オペレーションが想定と違いがうまくいかないことも
![Page 45: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/45.jpg)
After Aurora
SQLコマンドで障害のシミュレーション可能
インスタンスのクラッシュのような全体障害
NW、Disk等の部分障害
万が一の障害時のオペレーションが簡単にシミュレートでき、復旧の確実性が上がる
![Page 46: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/46.jpg)
Cache Warming
![Page 47: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/47.jpg)
Before
InnoDB Buffer Pool Dump(5.6~)
Query CacheはWarming不可
mysqldが止まると消える(InnoDB Buffer Pool Dump以外)
再起動直後は性能が落ちる
![Page 48: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/48.jpg)
After AuroraCache機構は別プロセス
Shutdown(正確にはreboot)しても消えない
再起動時の性能が安定する
デフォルトONなくらいだし、きっとQuery Cacheのこと(と思っていた)
InnoDB Buffer Pool Dumpの設定はそれはそれであるので、必要な場合は要設定(と思っていた)
え?それじゃ、、、?
![Page 49: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/49.jpg)
Auroraへの移行方法 使いたくなってきましたか?
![Page 50: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/50.jpg)
基本的にはRDSと同じmysqldump
RDS for MySQLからならスナップショットマイグレーションが可能ただし、innodb_file_per_table=1だとNG
無停止(に近い)移行ならRDS Slaveにmysqldump --single-transaction --master-data=2 (あるいは--dump-slave=2)のデータをインポートして、外部Msaterにぶらさげる方式で行けそう(時間切れで検証できませんでした…Preview来たの5日前…orz)http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.NonRDSRepl.html
![Page 51: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/51.jpg)
まとめと感想Auroraが革新的で素晴らしいのはたしかにそう
特に運用面では優位性が際立つ
どんなものにも向き不向きがある
MySQLの先が不安だからとか、好き嫌いとかで選ぶものではない
小中規模のMySQLよりもむしろ、OracleRACとかエンタープライズの方が乗り換え対象では?
そもそも小さいサイズのインスタンスは提供予定が今のところない
大規模MySQLはAuroraの優位点は大いにあるので、要件とワークロード次第
Auroraに限らず、新しいものの導入に際しては検証をしよう
![Page 52: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/52.jpg)
Limited Preview中につき、今後変わる可能性があります。
![Page 53: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/53.jpg)
Previw来てる方、これから来る方まずは色々弄ってみましょう その時、今日のお話を思い出していただければ幸いです
![Page 54: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/54.jpg)
MySQLerならAurora弄るの楽しいはず(・∀・)
MySQLっぽいけどMySQLじゃない感じが触ってて面白いまだ途上なので、いっぱい触っていっぱいフィードバックすれば、
より良いものになるはず!
![Page 55: [Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://reader037.vdocuments.pub/reader037/viewer/2022102701/55a8abf21a28ab842a8b46ee/html5/thumbnails/55.jpg)
ありがとうございました! ここでは言えない話はPub Crawlでこっそり?w