00:06
5月3日、水曜日ですね。 時刻は昨日10分になりました。
マキさんとプテラノードさんですね。 ご参加いただきありがとうございます。
今から冒頭の記事をダラダラと 読んでいこうと思っています。
先ほど言いましたけど、昨日が6章まで。 一応言いますと、コードベース、依存関係、
あと設定、バックエンドサービス、 ビルド、リリース、実行、そしてプロセスですね。
そのところまで読み切ったので、 今日は第7章、ポートバインディングから
入っていきたいなと思っています。では早速いきましょう。
ポートバインディングを通してサービスを公開する。
ウェブアプリケーションはウェブサーバー コンテナの内部で実行されることがある。
例えば、PHPアプリケーションは Apache HDBD内部のモジュールとして
実行されるかもしれないし、Javaアプリケーションは Tomcatの内部で実行されるかもしれません。
TWELVE-FACTOR APPは完全に自己完結し、 ウェブに公開されるサービスを作成するために、
コンテナが実行環境にウェブサーバーランタイムを 注入することを頼りにしません。
ウェブアプリケーションはポートにバインドすることで
HTTPをサービスとして公開し、 そのポートにリクエストが来るのを待つ。
ローカル化の開発環境で開発者はアプリケーションによって 公開されたサービスにアクセスするために、
例えば、HTTP//ローカルホストコロン5000 みたいなURLにアクセスします。
本番環境ではルーティング層が外向きのホスト名から ポートにバインドされた
ウェブプロセスへとリクエストをルーティングします。
これは一般に依存関係宣言を使って、ウェブサーバーライブラリを アプリケーションに追加することで実装されます。
ウェブサーバーライブラリの例として、
PythonにおけるTornadoとかRubyにおけるThinとか、
Javaやその他のJVMベースの言語におけるJettyなどがあります。
これはユーザー空間、すなわちアプリケーションの コード外で完結をします。
リクエストを処理するための実行環境との契約は ポートをバインドすることになります。
まあまあまあ、そうねって感じですね。
ポートバインディングによって 公開されるサービスはHTTPだけではない。
ほぼ全てのサーバーソフトウェアというものは、
ポートをバインドするプロセスを用いて動作し、
リクエストが来るのを待ちます。
例として、XMPPを話すなんかよくわからないライブラリと、
あとレディースとか、プロトコルを話すレディースなどが一応あります。
ここで注目すべきは、ポートバインディングの方法によって、
あるアプリケーションが他のアプリケーションにとっての バックエンドサービスになれる点になります。
で、バックエンドアプリケーションへのURLを提供し、
利用するアプリケーションの設定に、
リソースハンドルとして格納すればよいということですね。
まあ確かにこれはそうだよなって感じがしますね。
なるほどでした。
以上、ちょっと短いですけど、ポートバインディングは以上で、
続きまして8章ですね。
平行性の話に移っていきたいと思います。
プロセスモデルによってスケールアウトをするという 平行性の話です。
すべてのコンピュータプログラムというのは、
一度実行されると、一つ以上のプロセスとして表されます。
Webアプリケーションでは様々なプロセス実行形態が取られてきました。
例えばPHPのプロセスは、
03:01
Apacheの個プロセスとして実行され、
リクエスト量に応じて起動されますと。
Javaプロセスは反対の方法を取ります。
JVMが一つの巨大な親プロセスを提供し、
起動時にシステムリソース、
CPUとかメモリなどの大きなブロックを確保し、
スレッドを使って内部的に平行性を管理すると。
どちらの場合でも実行されるプロセスは、
アプリケーションの開発者にほとんど見えませんということですね。
処理の仕方はウェブサーバーごとによって違ったりしますからね。
12ファクターアップでは、
プロセスは第一級市民であります。
この12ファクターアップにおけるプロセスの考え方というのは、
サービスのデーモンを実行するための
ユニックスプロセスモデルから大きなヒントを得ています。
このモデルを使い、
個々のワークロードの種類をプロセスタイプに割り当てることで、
開発者はアプリケーションが多様なワークロードを
扱えるように設計することができます。
例えば、HTTPリクエストは
ウェブプロセスによって処理し、
時間のかかるバックグラウンドタスクというのは
ワークアッププロセスによって処理することができます。
このモデルはランタイムVM内のスレッドや
イベントマシンや
Twisted、
もしくはNode.jsなどの非同期イベントのモデルによって
個々のプロセスがプロセス内部で多重化することを
禁止するわけでもありません。
なんか知らない名前がポンポン出てきて、
不運と思ってますが。
しかし、個々のVMはそれほど大きくなる。
垂直にスケールすることができません。
そのため、アプリケーションは
複数の物理マシンで動作する
複数のプロセスへと拡大できなければならない。
このプロセスモデルが進化を発揮するのは
スケールアウトが必要になった時になります。
シェアドナッシングで水平分割可能な
12ファクターアッププロセスの性質というものは
平行性を高める操作が単純かつ確実なものであることを
意味します。
プロセスタイプとそれぞれのタイプの
プロセス数の配列は
プロセスフォーメーションと呼ばれたりします。
12ファクターアップのプロセスは
決してデモン化するべきではないし
PIDファイルを書き出すべきでもない。
その代わりにOSのプロセスマネージャー
例えばシステムDとか
クラウドプラットフォームの分散プロセスマネージャーとか
あるいは開発環境における
フォーマンのようなツールに頼ることで
出力ストリームを管理し
プロセスのクラッシュに対応し
ユーザーによる再起動やシャットダウンを
処理するべきですよということですね。
プロセスは決してデモン化するべきではない
というのがこのファクターアップの思想なんですね。
なるほどでした。
結構共感もあるし
実際今のウェブサーバー周りって
そんな感じの設計になってるよねっていう話も
結構多いので
やっぱりつくづく
だいぶ前からこの設計思想を
しっかりまとめられてるって
すげーなって思いますね。
第9章
廃棄容易性ってやつですね。
高速な起動と
グレースフルシャットダウンで
堅牢性を最大化するという話です。
12ファクターアップのプロセスっていうのは
廃棄容易であります。
すなわち即座に起動
もしくは終了することができると。
この性質が素早く柔軟なスケールと
コードや設定に対する
変更の素早いデプロイを容易にし
本番デプロイの堅牢性を高めますと。
プロセスは起動時間を最小化するように
努力すべきであります。
06:00
理想的な一つのプロセスは
起動コマンドが実行されてから
数秒間でリクエストやジョブを受け取れるようになるべきであります。
起動時間が短いとリリース作業や
スケールアップのアジリティが高くなります。
そりゃそうだよね。
さらにプロセスマネージャーが
必要に応じてプロセスは新しい物理マシンに
簡単に移動できるようにもなるため
堅牢性も高くなります。
プロセスはプロセスマネージャーが
SIGタイムタイムシグナルを受け取ったときに
グレースフルにシャットダウンします。
Web プロセスの場合
グレースフルシャットダウンは
サービスポートのリッスンを中止し
したがって新しいリクエストを拒んでしまうということですけど
リッスンを中止して
処理中のリクエストが終了するまで待ち
シャットダウンすることで実現されます。
このモデルでは
暗黙的にhttpリクエストが短い
せいぜい数秒ということを
仮定しています。
ロングポーリングの場合は
クライアントはコネクションが失われたときに
途切れなく再接続を試みるべきであります。
ワーカープロセスの場合は
グレースフルシャットダウンというのは
処理中のジョブをワーカー級に戻すことで
実現される。
例えばラビットMQでは
ワーカーをナックというものを
送ることができます。
これは多分信号かな。
ビンストークデータ
ストークDか
ではワーカーの接続が失われると
ジョブは自動的に急に戻ります。
リレイドジョブなどのロックを
ベースにしたシステムでは
ジョブレコードのロックを確実に解放する
必要があります。
このモデルでは
暗黙的にすべてのジョブが
再入可能であることを仮定しています。
再入可能性は一般的に
結果をトランザクションで進んだり
処理をべきとにすることで実現されます。
はいはいはい。
また仮想のハードウェアの
障害に関して言えば
プロセスは突然の死に対して
堅牢であるべきであります。
このような事態が起こることは
SIGタームによるグレースフルシャットダウンに
比べればずっと少ないが
それでもまあ起こりうります。
この対策として推奨される方法は
ビンストークDなどのような
堅牢なキューイングバックエンドを使って
クライアントの接続が
切断されたりタイムアウトしたときに
ジョブを急に戻せるようにすることです。
どちらにしても
12ファクターアップは
予期しないグレースフルでない停止を
うまく処理できるよう設計されています。
クラッシュオンリー設計はこのコンセプトを
論理的規決に導きます。
またこのクラッシュオンリー設計
というところが
別の記事のリンクが貼られているので
興味ある人は見てみてください。
またその論理的規決というところも
別の記事のリンクが貼られています。
それも見てみてください。
overreview.htmlですね。
では続きまして
第10章ですね。
ここで開発・本番一致という話です。
開発ステージン環境
本番環境をできるだけ一致させた状態を
保ちましょうという話です。
歴史的に開発環境
開発者が直接変更するアプリケーションの
ローカルデプロイと
本番環境
エンドユーザーがアクセスされるアプリケーションの
実行中デプロイの間には
大きなギャップがありました。
これらのギャップは3つの領域で現れます。
1つは時間のギャップです。
開発者が編集したコードが
本番に反映されるまで数日、数週間
09:00
時には数ヶ月かかることがあります。
2つ目は人材のギャップです。
開発者が書いたコードを
インフラエンジニアがデプロイする
今は自動デプロイになってたりするケースのほうが
多いと思うのでインフラエンジニアとは限りませんけど
このドキュメントを書いているときは
インフラエンジニアということですね。
3つ目はツールのギャップです。
本番デプロイでは
ApacheとかMySQLとかLinuxを使うのに
開発者がEngineX、SQLite、OS Xのような
スタックを使うことがありますので
ツールのギャップもあります。
12ファクターアップでは
継続的デプロイをしやすいように
開発環境と本番環境のギャップを
小さく保ちます。
上で述べた3つのギャップを見ていきましょう。
まず時間のギャップを小さくするということですけど
これは開発者が書いたコードは数時間後
さらには数分後はデプロイされるようにしましょう。
結局は自動デプロイしようということだと思うんです。
続いて2つ目の
人材のギャップを小さくするですけど
コードを書いた開発者は
そのコードのデプロイに深くかかわり
そのコードの本番環境の挙動をモニタリングする。
3つ目はツールのギャップを小さくするですけど
開発環境と本番環境をできるだけ一致させた状態を保つ。
そういう思想のためにDockerコンテナとか
生まれたんだろうなと思ってますね。
上で述べたことを表にまとめますと
こんな感じで
今言ったことを表にまとめているということですね。
縦軸に伝統的なアプリケーションと
12ファクターアップという縦軸で
横軸はさっきのデプロイの間隔と
コードを書く人とデプロイする人というところと
開発環境と本番環境みたいなところですね。
バックエンドサービス
アプリケーションのデータベースとか
キューイングシステムとか
キャッシュとかなどなどみたいな
バックエンドサービスっていうものは
開発本番一致が重要になる領域の一つであります。
そりゃそうだよね。
多くの言語は
異なる種類のサービスへのアダプターを含め
バックエンドサービスへのアクセスを
単純化するライブラリーを提供しています。
以下の表にいくつかの例を示しますけど
言語だったりライブラリーだったり
アダプターですね。
データベース・キュー・キャッシュですけど
例えばRubyとかRailsだったら
ライブラリーはアクティブレコードになるし
アダプターとしては
マイアスケールとか
ボスグレとか
エスキュライトとかですね。
データベース周りだとそうなります。
キューのサービスでいくと
Python、Djangoどこかだと
ライブラリーは
Celeryってやつですかね。
ラビットMQだったり
Bins TalkDだったり
Redisだったりとか。
キャッシュ周りの話だと
言語だとRubyRailsの例ですけど
アクティブサポート
アクティブサポートのキャッシュってやつがあるんですね。
あとメモリーとかファイルシステムとか
MemcacheDとかですね。
などなどです。
本番環境では
より本格的で堅牢なバックエンドサービスが
使われるにもかかわらず
開発者は自身のローカル開発環境で
軽量なバックエンドサービスを
使いたくなることもあります。
例えば開発環境では
エスキュライトを使い
本番では
ボスグレを使ったりとかですね。
開発環境では
ローカルプロセスのメモリーを
キャッシュに使い
本番ではMemcacheDを
使ったりするのであります。
開発と本番で
データベース違いは
今はないんじゃないですかね。
昔は多分
お金とか何たらかんたらで
あったんでしょうけど。
あと本番では
MemcacheD使ってるけど
ローカルで使わないは
12:00
まだ何か聞いたことあるんで
そうなのかもしれないなって感じですね。
はい。
例え理論的には
アダプターが
バックエンドサービスの違いを
全て中小化してくれるとしても
12ファクターの開発者は
開発と本番の間で
異なるバックエンドサービスを
使いたくなる衝動に
抵抗をしますと。
バックエンドサービスの違いは
わずかな非互換性が
顕在化し
開発環境や
ステージング環境では
正常に動作して
テストも通過する行動が
本番環境で
エラーを起こす
事態を招くことを
意味しますと。
まあそうね。
この種のエラーは
継続的デプロイを
妨げる摩擦
ってのも産みます。
この摩擦と
それに従って
継続的デプロイが
コストっていうのは
アプリケーションの
ライフサイクルに
わたってトータルで
考えると非常に高く
つきますと。
まあそうだよね。
これは。
やっぱり摩擦はないに
越したことはないですし
環境ごとの摩擦なんて
まあ大体あの
あれですね
塞いでしかないのでね。
で、軽量な
ローカルサービス
っていうのは
以前ほど魅力的な
ものではなくなって
きています。
Memcachedとか
PostgreSQLとか
RabbitMQなどの
モダンなバックエンド
サービスっていうのは
Homebrewや
aptgetなどの
パッケージシステムの
おかげで
簡単にインストールして
実行できるようになりました。
あるいは
ChefとかPuppet
などの宣言的な
プロビジョニングツールと
BayGrantなどの
軽量な仮想環境を
組み合わせることで
開発者を本番環境に
限りなく近い
ローカル環境を
作ることができますと。
まあ出てくるツールの
名前がだいぶ古いな
っていうのはさすが
確かに
このドキュメントの
初回転
2010年ぐらいでしたっけ
最終アップデートも
確か2017年で
それでもやっぱり
古いなっていう感じですね
Chefとか久しぶりに
聞きましたしね
BayGrantもかなり
久しぶりに聞いた
戻ります。
開発とか本番位置
というところですけど
継続デプロイの利益に
比べると
これらのシステムを
インストールして
利用するコストは
全然低いですよね
って話です。
異なるバックエンド
サービスへのアダプター
というのは依然有用で
ありますと。
これらのアダプターは
新しいバックエンド
サービスに移植する時の
苦痛を比較的
和らげてくれるためになります。
全てのデプロイ
開発、ステージング、
本番環境というのは
同じ種類かつ
同じバージョンの
バックエンドサービスを
利用するべき
ということですよね。
はい、というところでした。
やっぱりインフラとか
レイヤーが低いところは
さすがに一致してもらわないと
困りますよね。
ありますよね。
どちらにしても
アプリケーションというのは
その土台の上に
乗っかってくるもので
土台が崩れてるとか
土台が一致しない
というのはさすがに
そうだよねって話だと思うので。
そのための
仮想化技術が
どんどん進んだというのは
本当大きいなと思ってますね。
はい。
続いて
セクション11ですね。
次はログのお話です。
ログを
イベントストリームとして
扱いましょうという話です。
ログは
実行中のアプリケーションの
挙動を可視化します。
サーバーベースの環境では
ログは一般的に
ディスク上のファイル
ログファイルに書き込まれます。
しかしこれは
出力フォーマットの
一つにすぎませんと。
ログは
全ての実行中の
プロセスと
バックエンドサービスの
出力ストリームから
収集されたイベントが
集約されて
時刻の順に並べられた
ストリームであります。
そうだよね。
生の状態のログっていうのは
通常
一行が一つのイベントを
表すテキストフォーマットである。
例外のバックトレースは
複数行に渡る場合もあるが
基本的には
一行一つのイベント
ということですね。
ログには
15:00
固定の始まりと
終わりはなく
アプリケーションが
稼働している限り
流れ続けますと。
ちゃんと集約
吐き出していれば
ということですよね。
アプリケーションは
ログファイルに書き込んだり
管理しようとしたり
するべきではないようと。
代わりに
それぞれの実行中の
プロセスは
イベントストリームを
スタンダードアウトですね。
標準出力に
バックファイリングせずに
書き出しましょうと。
ローカルでの開発者を
このストリームを
ターミナルの
フォアグランドで見ることで
アプリケーションの
出力ストリームを
管理しようとしたり
するべきではないようと。
代わりに
それぞれの実行中の
プロセスは
バックファイリングせずに
書き出しましょうと。
ローカルでの開発者を
このストリームを
ターミナルの
フォアグランドで見ることで
アプリケーションの
挙動を観察しますと。
まあそうね。
まあだけど
ローカルでも
書き出すときは
ログファイルとして
書き出しておいた方が
いいと思いますけど。
ステージング環境や
本番のデプロイでは
それぞれのプロセスの
ストリームは
実行環境に捉えられ
アプリケーションからの
他の全ての
ストリームと
一緒に並べられ
長期アーカイブのために
一つもしくは複数の
最終目的地にも
送られますと。
これらの保存のための
目的地は
アプリケーションから
見ることも
設定することもできず
代わりに
実行環境によって
完全に管理されます。
まあそうだよね。
ログプレックスや
フルエントDですね。
などの
オープンソースの
ログルーターが
この目的に利用できますと。
ログプレックスは
僕は初めて聞きました。
フルエントDは
確か今も全然
元気で使われている
印象がありますね。
アプリケーションの
イベントストリームというのは
ファイルに送られたり
ターミナルで
テールを使って
リアルタイムに
見られたりもしますと。
テールコマンド
確かに使ってましたね。
最も重要な
用途としては
ストリームというのは
スプランクなどの
ログインデックスですね。
とか解析システムとか
Hadoop、Hiveなどの
汎用データウェアですね。
データウェアハウスシステム
などに
送られることも
ありますと。
Hadoopも
久しぶりに聞きましたね。
ちょっと僕
全然やってないけど
今も使われてるのかな
わかんないけど。
これらのシステムは
長期にわたって
アプリケーションの
挙動を確認するための
大きな力と
柔軟性をもたらし
次のようなことが
できるようになりますと。
過去の
特定のイベントを
見つけるとか
大きなスケールの
傾向を
グラフ化するとかですね。
1分あたりの
リクエスト数など
だろうですけど。
あとは
ユーザー定義の
ヒューリスティックに
基づいて
素早くアラートを
出すとかですね。
こちらも1分あたりの
認識位置を超えた場合に
アラートを出すなど
みたいなことも
柔軟に使ったり
設定することも
できますよね
っていうことでした。
ログはやっぱ大事だよな
本当に。
僕フロントの
開発ばっかりしか
やってないので
ログの話とか
ほとんど
最近やらなくなったんですけど
やっぱ大事だよな
と思います。
ではラストですね。
12章
管理プロセスの
話です。
管理タスクを
1回限りの
プロセスとして
実行するという
話です。
プロセスフォーメーション
っていうのは
アプリケーションが
使われたときに
アプリケーションの
通常の役割
いわゆる
ウェブリクエストの
処理などに
使われるプロセス群
になりますと。
それとは別に
開発者はしばしば
アプリケーションのために
1回限りの管理
メンテナンス用の
タスクを
実行したくなる。
例えば
データベースの
マイグレーションを
18:00
実行するですね。
Jangoにおける
manage.pyの
マイグレートみたいな
コマンドですね。
Railsにおける
rake-db-colon
マイグレートみたいな
コマンドですね。
任意のコードを
実行したり
生のデータベースに対して
アプリケーションの
モデルを調査したり
するために
コンソールですね。
を実行します。
多くの言語では
インタープリターを
引数なしで実行する。
例えば
PythonやPerl
ということですね。
ことで
RAPLを利用できますけど
別のコマンドを
用意している場合も
ありますと。
Rubyでの
IRBとか
Railsでの
Railsコンソールみたいな
やつも
あったりします。
あとは
アプリケーションの
リポジトリに
コミットされた
例えば
PHPスペース
スクリプト
スラッシュ
なんちゃら
かんちゃら
.PHPみたいな
やつですね。
を個別に
実行する場合など
1回限りの
管理メンテナンス用の
タスクを実行したくなる時
というのが
開発者としては
ままありますと。
1回限りの
管理プロセスというのは
アプリケーションの
通常の長時間
実行されるプロセスと
全く同じ環境で
実行されるべきであります。
これらのプロセスは
あるリリースに対して
実行され
そのリリースに対して
そうでしょうね。
管理用のコードというのは
その同期の問題を
避けるために
アプリケーションコードと
一緒にデプロイされる
べきでもありますよと。
同じ依存関係分離技術
というのを
全てのプロセスタイプにも
利用すべきですと。
依存関係分離技術
というのは
このファクターの中の
ディペンデンシーですね。
依存性というのが
確か参照に
あった気がするので
その技術を
使いましょうと。
こちら全ての
プロセスタイプに
利用すべきです。
例えばもし
Rubyの
バンドルエグゼックの
SYNのスタート
みたいなものを
使うのであれば
データベースの
マイグレーションには
バンドルエグゼックの
RAKEの
DBコロマイグレート
を使うべきであります。
というふうに
ちゃんと一致する
同じものを
使うべきですよね。
同様に
バーチャルMを
使っている
Pythonプログラムでは
仮想環境内の
binスラッシュPython
というのを
トルネードウェブサーバーと
全ての
manage.pyの
管理プロセスの
両方で利用すべきですよ
12ファクターは
細かな設定なしで
すぐに使える
REPLシェルを
提供する言語を
強く好みます。
1回限りの
スクリプトを
実行するのが
簡単になるか
になりますよと。
ローカルデプロイでは
開発者は1回限りの
管理プロセスを
アプリケーション
チェックアウトした
ディレクトリの中で
シェルコマンドで
直接起動します。
本番デプロイでは
開発者は
SSHやデプロイの
実行環境が提供する
他のリモートコマンドを
実行方法を使って
このようなプロセスを
実行しますという
お話でした。
はい。
というところで
以上
The Twelve Factor Up
全12章ですね
読んでいきましたけど
いかがだったでしょうか。
いやこれ本当に
だいぶ古い
ブログじゃないですね
ドキュメントで
僕も本当
だいぶ前ですね
に紹介されたやつ
なんですけど
改めて読んだんですが
そんな古い時の
ドキュメントが
未だに全然
適用されてるな
っていうのを
つくず感じるし
使ってるツールとか
インターフェースとか
やり方は
多少の変化はある
基本的な変化はある
根本的な設計とか
21:00
思想みたいなところは
だいぶこれに乗っかった
今設計になってるんだろうな
っていうのを
つくずく感じました。
はい。
やっぱり
バックエンドとか
インフラとか
そういう思想とか
設計周りの話って
なんだかんだ長く
使われるんだろうな
って感じますよね
こういうの見ると
っていうのと
昔の人たち
やっぱ頭いいんだな
と思わされましたね
今もこれが
ずっと適用されてるか
通用するんだもんな
っていう話なので
特に僕は
Git周りの
使い方とかが
まさにこの
ゼルファクターアップの
考え方は
そのまんまだな
っていうので
いやぁ
天才ってやっぱり
どこにでもいるんやな
って感じはありますけど
まあ
本当に良い
ドキュメントだった
と思いますし
新卒の方々とか
新人の方々
駆け出しの方々に
この辺読んでいただいても
いいのかなと思ってます
読んで
その上で
この設計思想を見ながら
他のツールとか
実際の開発環境
どうなんだろう
っていうのを
照らし合わせてみていくと
結構一致するものがあって
いいんだなっていうか
そういう考え方を
実装してもらえたら
いいんじゃないかな
というふうに
思ったりもしたので
なんとなければ
僕個人は勝手に
新卒のメンバーとかに
これおすすめだよって
紹介していこうかな
と思ったりしました
まあもちろんこれが
正しいとか
これが正解だよって
わけではないですけど
結果的にこの
思想に乗っかった設計の
物はたくさんあるよ
っていう話ですね
まあでも参考には
すごくなると思いますし
今後どういう変化が
技術的なシンキュラリティが
起きるかは
わからないですけど
当分これは
なんか乗っかるんだろうな
という気はしてますね
というところで
はい
ちょっと僕の余談は
去ったわけで
こんな感じで
今日は終わっていきたい
と思います
改めまして
今日はマッキーさんと
プテラノドウさんと
ボウさんですね
ご参加いただき
大変にありがとうございました
明日なんか全然
また別の記事を
読んでいこうと思いますので
興味があれば
参加していただければ
すごく嬉しいな
と思っております
では5月3日ですね
今日から本当に本格的な
ゴールデンメイクに
入るって方々も
多分いらっしゃると思いますので
ゆっくりリフレッシュして
いただければな
と思います
では今日はここで
終了したいと思います
お疲れ様でした