読者です 読者をやめる 読者になる 読者になる

Fusicきばんブログ

Fusic基盤ユニットの非公式技術ブログ

CakePHP3の負荷テストでの落とし穴

CakePHP CakePHP3 Apache PHP

基盤ユニットの貞方(@sadapon2008)です。

CakePHP3のアプリをApacheBenchで負荷テストした際にはまった落とし穴をご紹介します。

前提

  • CentOS 7.3 + Apache 2.4 + PHP 7.0.17(remi版のmod_php)

落とし穴:ApacheBenchでCakePHP3の負荷テストをやってみたら全く性能が出ない

非常に簡単な負荷テストとして、静的HTML、素のPHP、CakePHP3.4.3でGETに対して簡単なHTMLを返すだけのものを用意し、 下記のコマンドでApacheBenchを実行してRequests per secondを測ってました。

$ ab -t 10 -c 20 -n 1000000 http://a.b.c.d/

すると、CakePHP3だけ3桁以上性能が悪い結果が出て(´・ω・`)となりました。 CakePHP3のデバッグモードはオフにしています。

  • 静的HTML: 約 8,000 req/s
  • 素のPHP: 約 7,500 req/s
  • CakePHP3: 約 2 req/s

原因

さすがにこの結果はおかしいだろうと原因を調査したところ、下記の記事を見つけました。

stackoverflow.com

PHP 5.4以上ではHTTPのリクエストのConnectionヘッダを指定しないとheader()が非常に遅くなるとのことでした。 CakePHP3のソースを見てみると↓の箇所で使っているheader()がまさに該当していました。

https://github.com/cakephp/cakephp/blob/3.4.3/src/Http/ResponseEmitter.php#L144

ワークアラウンド

前述の記事を参考にab -kを指定してConnection: keep-aliveが有効になるようにしてみました。

$ ab -t 10 -c 20 -n 1000000 -k http://a.b.c.d/

その結果、かなり改善しました!

  • CakePHP3 before: 約 2 req/s
  • CakePHP3 after: 約 700 req/s

元記事によるとクローラーなど行儀の悪いクライアントはConnectionヘッダが欠落していることもあるとのことなので、例えばApacheなら以下のような設定を行うことで、Connectionヘッダを強制することが可能です。

SetEnvIfNoCase Connection "^(keep-alive|close)$" APP_CONNECTION=1
RequestHeader set Connection close env=!APP_CONNECTION

↑の設定をすると-kを指定せずとも同じくらいの結果が得られました。

Rust言語でゆるくツールを作ってみるお話

Fusicの中野です。

最近、弊社の東京事務所内で人気のRust(プログラミング言語)について。

Rust言語

Rust言語についてのイメージは

  • 所有権と借用
  • 難しい
  • GCがない
  • 速いっぽい

とかでしょうか。

特に、所有権と借用のメモリ管理まわりの概念が、少し難しい言語かなと思います。

しかし、パターンマッチ・型推論・総称型・マクロなど、とても魅力的な要素がたくさん ある言語なので、今回はRust言語の勉強用にちょっとしたツールを作ってみました。

作ってみたツール

ということで、

github.com

主な機能として

  • $HOME/.ssh/config をパースする
  • Host <何か> の何か部分を取り出して、tmuxのパネルを分割してSSHで接続
  • それぞれの接続先にコマンドを送りつける

です。

使用したライブラリとして、

$HOME/.ssh/configのパース => rust版parsecのnom
readlineっぽいやつ => liner

を使わせていただきました。

nomはparsecとそっくりだったので、exampleとガヴリールドロップアウトを見ながら、 さくっと利用する事ができました。

感想として

Rustは難しい部分もあるかと思いますが、コンパイルが通れば気持ちいいですし そこそこ想定通りの動きをしてくれます。

rustup・rustfmt・racerなどの開発用ツールや、Rustの日本語記事や日本語訳ドキュメントなど、 簡単に利用するための環境が充実してきました。

Rust言語が気になっている人は、軽く試してみてはいかがでしょうか?

障害対応の裏側で何をやっているかの話

Fusic 平田です。
基盤ユニットの追加モジュール的な何かになりました。

何書こうかなーと思い、最近あったtypoとの悲しい戦い*1をまとめなおすとかでも良かったんですが、せっかくなので違う話を。

サイトが閲覧できない!な時に何をやっているか

障害対応なんかに遭遇しやすい、あるいは呼ばれやすい性質でして。
その時何やっているのかって話を少し。

あわてない、さわがない、はしらない

まあとりあえず。
何もいい結果に繋がらないので。

起きている状況をなるべく正確に知る

「全く閲覧できない」なのか、「閲覧できるけどすごく重い」なのか、それだけでも大きな違いなので、状況確認は正確に。

ネットワーク的に到達できるのか、サーバにログインできるのか

これすらできない場合は、

  • ネットワーク起因だったりするので周辺の状況(経路でネットワークダウンの障害報が出てないかなど)を確認する
  • OSがハングしている場合は、再起動を試みる

といった対応にシフトします。

リソースの使用状況の確認

dstatで確認することが多いです。
リソース監視を行っているのであれば、そのグラフ状況を見るなどして、リソースの使用状況を確認します。

  • メモリが枯渇している
  • CPUを使い過ぎている
  • I/O待ちが発生しまくっている

といった感じで、ボトルネックを特定します。

ログを見る

/var/log/ 以下であったり、アプリケーションのログであったりを確認して、特異な(OOM Killerなんかは特異の典型)ログが出ていないかを確認します。
特異点の判断ポイントとしては

  • 明らかに普段出ないログが出力されている
  • ログの量が普段より明らかに多い

といった観点になるでしょうか。

ただ目で追うのもさすがに辛いので、grepなりwcなり、コマンドと組み合わせて原因を探る感じです。

あと、アクセスログを精査するのであれば、Kataribeが便利です。
ISUCON御用達ツールですが、負荷の高い箇所だったりアクセス増だったりの一次調査で使えます。

対策を決めて実行する

原因が明確に特定できたのであれば、対応する内容も明確になります。
アプリケーションの修正であったり、ミドルウェアの設定値変更であったり。
緊急度と対応時間とを天秤にかけて、場合によっては一次対応(応急処置)と二次対応(抜本的な対策)を分けるケースもあります。

原因が分からないケース

というのも当然あるので、その際は出力するログを増やすなどして網を張るようにしています。

実例だとこんな感じ

1ヶ月ほど前に起きた事例ですが。

  1. 状況としては「繋がるけどすごく重い」 → OSがハングしているとか、全く手が付けられないわけではなさそう
  2. ssh繋いでみたところ、接続できた → 障害報もないし、ネットワークはあまり関係なさそう
  3. リソースを確認するとロードアベレージが異様に高い → CPU起因だから、どこかで重い処理が走っているとか?
  4. ログを確認すると、httpサーバのログが大量に出ている → アクセスが相当増えた?
  5. アクセスログを精査する → 特定のページに対してアクセスが集中していることが分かった(原因判明)
  6. 特定のページと関連リソース(ページ内の画像)に対して一時的にキャッシュするよう設定変更(対策)

実例その2

こんなケースも。

  1. 「サイトに繋がらない」 → あらゆる可能性あり
  2. ssh繋いでみたところ、接続できた → ネットワークはあまり関係なさそう、OSも大丈夫そう
  3. リソースはどれもおおむね問題なし → 明確な原因が不明
  4. ログを確認するが、どれも平常通り → 明確な原因が不明だけど、httpのプロセスがうまく動作しなくなっているのかもしれない
  5. 応急措置としてhttpサーバを再起動(一時対応)したら復旧した → 引き続き注視しつつ、ログを精査するなどして調査
  6. 特定の処理が重くて落ちた可能性がある → 開発環境で再現するかを検証(原因判明)
  7. 再現したのでアプリケーションを修正してリリース(抜本的な対策)

というわけで

何かものすごいことをやっている話ではないので恐縮なのですが、こんな感じで障害対応していますって話でした。

余談: ログをもっといい感じに可視化して集中管理したい

可視化 + 集中管理の仕組みを設ければ、調査系で呼ばれる回数が減りそうだなーと。
前時代感なまま過ごしていたんですが、この辺をKibanaに集めるような仕掛けをぼちぼち組まねばな、と。

って書いてしまったので、今年の前半はその辺を整備していきます。

*1:100以上のコミットを経て、ようやく落ち着いた。と思う。

cakephp/cakephp にPR 出してmerge された話

(Fusic Advent Calendar 24日目)http://qiita.com/advent-calendar/2016/fusic & (CakePHP3 AdventCalendar 24日目)http://qiita.com/JoJeongMin/items/9fbc4cc1de9268b5de56http://qiita.com/advent-calendar/2016/cakephp3です。

Fusic 新卒の濱野です。
基盤ユニットに配属されてまもなく半年。
周りの席にはその道10年の職人さんが多く座っているので、
いつもつらい気持ちで席についています。

そんな肩身の狭い新卒ですが、
最近少しだけ胸をはれることがありました!

それは、、、

http://bakery.cakephp.org/2016/12/11/cakephp_3310_released.html
f:id:adiboy:20161223210812p:plain

そう。cakephp の core に出したPR が merge されたのです!!!
これはめでたい!!!

ということで、今回は、PR がマージされるまでの模様を時系列に沿ってお伝えしようと思います。
これを機に、PRの数が増えるとうれしいです!!!

何なおしたの?

pagination のバグを修正しました。

$paginate = [
    'limit' => 30,
    'maxLimit' => 20,
];

という設定をした時に、

maxLimit => 20

が無視され、

limit => 30

が採用されていました。
つまり、 maxLimit がちゃんと動いていませんでした。

どうやって見つけたか?

プラグインを作っていたら、挙動がおかしかったのでcore を読みました。
ちなみに、core は極力読むようにしています。
そして、時々ブログなどに結果報告を書いています。

例1
例2

その癖をつけていたおかげで、割とすんなり問題箇所の特定ができました。
そして、何が原因なのかがわかりました。

issue を登録する

こんなissue を登録しました。
https://github.com/cakephp/cakephp/issues/9848

全部英語で書くのが意外と大変でした。

PR を投げる

ついでに、issue に紐付ける形でPR も出しました。

I showed an example to fix this bug in #9849 ,
please review it, and I expect for some comments.
If my PullRequest is not worth to merge, don't hesitate to close it.

って書いて。
超意訳すると、

一応このissue を解決するPR 送りますー  

っていう感じです。

https://github.com/cakephp/cakephp/pull/9849

中の人とやり取りする

PR を出すとすぐ、chinpei215さんが調整してくださいました。
そして、マージされるまで面倒を見てくださいました。
この場を借りてもう一度お礼させて頂きます。
本当に有難うございました。

結局やり取りをしたのは2人でした。
一人は前述のchinpei215さん。
もう一人は、dereuromarkさん。

お二方とやり取りし、コードを修正しました。
そして、気づいたらマージされていました。

PR を出してから Merge されるまで1日もかかりませんでした。

感想

中の人は、優しかったです。(もちろんご指摘も頂きましたが)
そして、社内の人から声をかけられる機会が増えました。
これからも何かあったらどんどんプルリク出していこうと思います。

以上、未経験から入った新人が (cakephp/cakephp)https://github.com/cakephp/cakephp/ にPR を送ってマージされた話でした!

FluentdのログフォーマットでS3に保存されたApacheのアクセスログをAmazon Athenaで集計する

AWS Fluentd

突然の Amazon Web Services Advent Calendar 2016 の 15日の記事です

基盤ユニットの小山 ( @k1LoW )です。

AWS re:Invent 2016すごかったですね。

数多くのサービスが使える形でリリースされてきました。

ただ、個人的にはその後の aws-sdk-ruby が v3に上がる というエントリーを見て、awspecをどうしようか戦々恐々としています。

突然のアクセスログ集計

あるAWS上に構築しているシステムプロジェクトで、突然「月単位でのアクセス集計1年間分」という要望がどこからともなく降ってきました。

そのプロジェクトでは、アクセスログを含む様々なメトリクスをFluentd ( td-agent ) で収集して、S3のバケットに保存しています。

ただ、保存の目的がいざという時のためで、稼働している分析基盤はありませんでした。

そこで、まずはローカルのMacBook ProでDigdag+MySQLによる集計を試みました。

が、

1日立ってもログ取得が終わらず。。。

(そういえば今まではdstatのような定期的に取得するメトリクス情報のログ集計で、アクセスログのようなさらに大量のデータの取得はしていなかった。。。)

さてどうしようかとなった時に、ふと思い出したのが、そう、Amazon Athenaでした。

そうだ、Amazon Athena を使ってみよう

f:id:k1LoW:20161214200312p:plain

aws.amazon.com

Amazon Athena、ざっくり紹介するとマネージドなPrestoです(ざっくりすぎる)。

AWS提供で、S3との相性がとてもよさそうなので、もしかしていけるのでは?と思って試してみたらできました。

前提

アクセスログは s3://[bucket-name]/access_logs/[ec2-hostname]/[year]/[month]/[day]/access_log.xxxxx.xxx.xxx.gz みたいに保存されています。

S3のバケット自体はap-northeast-1 (Tokyoリージョン)にあります(Amazon Athena自体はTokyoリージョンではまだ提供されていませんが、S3バケットの指定はできますよ!)。

実際のアクセスログはFluentdの一般的な(?)ログフォーマットで、

2016-12-19T04:35:27Z ip-10-xx-xxx-xxx    {"host":"xxx.xxx.xxx.xxx","user":"-","method":"GET","path":"/path/to/?q=query","code":"200","size":"1234","referer":"-","agent":"Some User-Agent"}

というような、タイムスタンプとhostnameとJSONの複合形式です。

テーブルの作成

本来ならば「Add Table」 リンクを押してデータベースの作成からするほうがいいのですが、今回は

Query Editorで、おもむろに以下のクエリを実行して集計用テーブルを作成しました。

CREATE EXTERNAL TABLE IF NOT EXISTS default.access_logs (
  date date,
  hour int,
  min int,
  second int,
  z string,
  host string ,
  ip string,
  user string,
  method string,
  path string,
  code int,
  size int,
  referer string,
  agent string
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe'
WITH SERDEPROPERTIES (
  'serialization.format' = '1',
  'input.regex' = '^(.+)T(\\d+):(\\d+):(\\d+)(.+)\\t([^\\s]+)\\t\\{"host":"([^"]+)","user":"([^"]+)","method":"([^"]+)","path":"([^"]+)","code":"([^"]+)","size":"([^"]+)","referer":"([^"]+)","agent":"([^"]+)"\\}'
) LOCATION 's3://[bucket-name]/access_logs/'

ポイントは 'input.regex' = '^(.+)T(\\d+):(\\d+):(\\d+)(.+)\\t([^\\s]+)\\t\\{"host":"([^"]+)","user":"([^"]+)","method":"([^"]+)","path":"([^"]+)","code":"([^"]+)","size":"([^"]+)","referer":"([^"]+)","agent":"([^"]+)"\\}' でFluentdのログフォーマットに合わせた正規表現を設定しているところです。

集計SQLの実行

ここからは簡単です。

1クエリごとに小さくない金額がかかりますが、突然の依頼なので悠長なことは言っていられません。

そこは札束で殴るように

SELECT MONTH(date) AS month, count(*), SUM(size) AS total_size
FROM rkb_web_public_access_logs
WHERE host IS NOT NULL
        AND date >= CAST('2016-01-01' AS DATE)
GROUP BY  MONTH(date) 
ORDER BY total_size DESC

などと、フルスキャンでがっつり集計などしました。

まとめ

Amazon Athenaは思った以上に気軽に使えました。

ただ、クエリごとに課金されるので、ご利用は計画的に。

突然のアクセスログ集計などには良いと思います。

よい突然ライフを。


おまけ

Dockerで開発環境・テスト環境を作る

Docker

こんにちは、2回目の登場になります。
基盤ユニットの櫻川です。

みなさんはDockerを利用してるでしょうか?

Fusicではまだまだ開発環境は Vagrantを複数立てる が主流ですが、 今はDockerの布教活動を行っている真っ最中です。

そもそもDockerを導入した目的

目的は 複数PHPのバージョンを同時に起動したい! です。

というのも、Fusicでは受託開発を行っていることもあり、プロジェクト毎に利用するPHPのバージョンやデータベースの種類・バージョンが異なること多いです。

そのため現在ではプロジェクト毎等でVagrantを新規で立ち上げたり、phpbrewを利用してPHPバージョンを切り替えたりして開発を行っています。

基本的にVagrantとphpbrewで複数PHPを利用することは可能だったのですが以下のような不満もありました。

  • Vagrant
    • 起動に時間がかかる
    • 複数起動すると結構重くなる
  • phpbrew
    • バージョン切り替えにApacheの設定を変える必要がある
    • 同一サーバー内で同時に複数バージョンを起動できない

そこで全てを解決してくれるDockerの出番なわけですよ!

利用している環境

Windowsです。
ただ、Docker自体はVM上のCentOS7で実行しているのでMacでも問題ないと思います。

  • Windows
  • Vagrant
  • Hyper-V
  • CentOS7(ホストOS)
    • Apache(リバースプロキシ用)
  • Docker + Docker Compose
    • Apache + PHP
    • Postgres
    • MySQL
    • samba

Dockerの構成

Dockerのコンテナをポート転送を設定して、最低でも3台のコンテナを起動しています。 ※必要なPHPのバージョン分 + データベース(Postgres or MySQL) + samba

この時点で「複数のPHPバージョンを同時に触りたい」という目的は達成しています。

ただし、このままだとDockerのポート転送を使っているので、PHPにアクセスするときのURLが http://example.com:8080/hoge/fuga というようにポート指定が必要になってきます。

ポート指定 をするのは嫌なのでDockerコンテナの前にリバースプロキシを置くことでポート指定をすることなく複数のPHPにアクセスすることを実現しています。
これで完全に目的達成!

また、ファイルの修正自体はsambaを経由して行っています。

f:id:sakutarou:20161201003230p:plain

どうやって作るの?

1. Dockerインストール

DockerをホストOS(CentOS7)にインストールします。

tee /etc/yum.repos.d/docker.repo <<-'EOF'
[dockerrepo]
name=Docker Repository
baseurl=https://yum.dockerproject.org/repo/main/centos/7/
enabled=1
gpgcheck=1
gpgkey=https://yum.dockerproject.org/gpg
EOF

yum install docker-engine
systemctl enable docker.service
systemctl start docker

2. sambaコンテナを立てる

samba用コンテナをCentOS6で起動します。
※dockerコンテナ内のsambaの設定は行ってください。
 yum install samba など
※ホストOS上の /var/www/html をsambaコンテナでマウントしています

docker run -itd --name samba -p 139:139 -p 445:445 -v /var/www/html:/var/www/html centos:6 /bin/bash

3. Postgresコンテナを立てる

Postgres用イメージを利用してPostgresコンテナを起動します。
MySQLでもかまいません。
{Postgresパスワード} はパスワードを設定してください

docker run --name postgres -e POSTGRES_PASSWORD={Postgresパスワード} -d -p 5432:5432 -e PGDATA=/var/lib/postgresql96/data postgres

4. Apache + PHPコンテナを起動する

Apache + PHPコンテナをCentOS6で起動します。
※dockerコンテナ内のApache + PHPの設定は行ってください。

PHPの必要なバージョン分コンテナを起動します。

docker run -itd --name PHP -p 8080:80 -p 443:443 --link postgres --volumes-from=samba centos:6 /bin/bash

5. ホストOS上でリバースプロキシを設定する。

ホストOSにApacheをインストールし、リバースプロキシを設定します。
※コンテナ上にApacheを立ててリバースプロキシを行ってもいいのですが、dockerを知らない人でも触りやすいようにホストOS上にApacheをインストールしています。

PHPを複数起動したいので、実際はVertualHostと組み合わせています。

ProxyRequests Off
ProxyPass / http://hoge.example.com:8080/
ProxyPassReverse / http://hoge.example.com:8080/

6. イメージをAmazon ECR上に保存する

実行しているDockerコンテナをイメージ化して、ECR上に保存してます。

  • ECR上にリポジトリを構築しておいてください。
  • aws cliをインストールしておいてください。
docker commit samba samba
docker commit php

aws ecr get-login --region ap-northeast-1
出力されたログインコマンドを実行

docker tag samba 発行されたECR用sambaリポジトリURL
docker tag php 発行されたECR用phpリポジトリURL

docker push 発行されたECR用sambaリポジトリURL
docker push 発行されたECR用phpリポジトリURL

最後

上記を実行することで最低限のPHP開発・テスト環境を構築することができます。
ただ、公開環境で起動する場合は公開するポート等セキュリティに注意してください。

また、このままだと起動するのが非常に手間なので、Dockerfile + Docker Composeにまとめています。

Dockerを使ったことない人は是非!

ガラケー対応の話

CakePHP3

Fusic 基盤ユニットの濱野(@gorogoroyasu) です。
全く未経験から入社した、2016年入社の新卒です。 諸先輩方のように圧倒的な記事はかけないので、僕のスマホ遍歴でも書いていこうと思います。

僕のスマホ遍歴

iPhone 4S  
iPhone 4 (4Sがアスファルトに直撃して画面が全壊したのでヤフオクで購入。この子は最終的に裏面が全壊)  
iPhone 5S  
arrows M02 (あまりに動作が遅く、親に譲った。使用期間半年。)
iPhone SE (←今)

ずっとiPhone を使っていたからAndroid を偵察してみよう! と思って買った arrows M02 が想像以上の遅さで、
これまで以上にiPhone が好きになった。

ちなみに、最後に使ってたガラケーのことはさっぱり覚えてない。

ガラケー対応プラグインの必要性

そんな僕が、ガラケー対応のプラグインを作成した。
理由は、スマホのシェアがそこまで高くないから。
ここにシェアがまとめてある。
www.nikkei.com

その中から抜粋すると、
スマホの普及率 : 67.4%(前年度比6.8ポイント増)
スマホ以外の普及率 : 64.3%(前年度比5.5ポイント減)
という感じ。

依然としてガラケーユーザーもいる模様。
(ガラケーでWeb サイトを閲覧する人がどれだけいるのかは別の話。通話はガラケーとかいうめんどくさい選択をしている人もいるし。。。)

しかし、なぜガラケー用のプラグインなるものが必要になるのか?
それは、、、

PC、スマホとガラケーでは、色々な違いがあるから。

たくさん違いがあるが、個人的に重要だと思う違いは、
1) 文字コード
2) クッキー使用の可否
3) 外部CSS の読み込み
4) JavaScript 使用の可否
の4つ。
それぞれ簡単に説明していく。

1) 文字コード
最近のPC,スマホサイトには、文字コードは"UTF-8" が採用される。
しかし、ガラケーの文字コードは"Shift-JIS" である可能性が高い。
可能性が高いと言っているのは、
携帯キャリア、製造年月によってはUTF-8 が使用できることがあるからだ。
しかし、大事なのは、文字コードは "Shift-JIS" を使った方が安全だということだ。
ということで、全ての文字は、 UTF-8 から Shift-JIS に変換されなくてはならない。
めんどくさい。

2) クッキー使用の可否
基本的に、ガラケーではクッキーを使うことができない。
では、どうやってログイン情報等を管理するか?
URL の末尾にセッションID をつける。
それにより、ログイン情報等を管理する。
実に原始的。めんどくさい。

3) 外部CSS の読み込み ガラケーでは外部CSS が使用できない(ことが多い)。
そのため、CSS を直書きする必要がある。

<div class="hoge" style="color: green;">hoge</div>   

みたいな感じ。
めんどくさい。

4) JavaScript 使用の可否
基本的にガラケーではJS を使うことができない。
悲しい。

と、ざっくり上げただけでも4つの違いがある。
特に面倒くさいのは1) と 2) 。
ここらへん、なんとかしたい!!

作ったプラグイン

ということで、 上記 1) と 2) をいい感じで解決するプラグインを作った。

--- 追記 ---

何のプラグインを作ったかが文章だけで分からないというご指摘をいただき追記。 作成したプラグインは、CakePHP3 用のものです。

--- 追記終わり ---

本当は 3) もなかなかめんどくさいんだけど、
いい感じにテンプレートとか拾ってきて対応して下さいー。

一言対応策

1) 文字コード
本プラグインでは、文字列の変換を

public function afterLayout(Event $Event, $layoutFile)  

で行った。
詳細は Garak/src/View/Helper/EncodeHelper.php
を参照。

2) クッキー問題
redirect をいじって、クッキー情報をクエリに持たせた。
詳細は、k1low/yak を参考に実装。

プラグインはcomposer を使って ここ からインストールできます。
名前は、 "Garak" !

ぜひ使ってみて下さい。

と、言いたいけど、
近い未来このプラグインが不要になることを願ってやみません。

あとがき

というわけで、初めてのチームブログを書かせて頂きました。
いかがでしたか? よかったら、コメントなりなんなりよろしくお願いしますー。