GCVE の VM でも Cloud Load Balancing を使いたい！ — Traffic Director 編
皆さん、こんにちは。Google Cloud で IaaS 領域を担当する Customer Engineer をしている Takao です。今回はコンテナではないコンピューティング基盤を使っている場合においても Traffic Director の便利さを知ってほしい、ということで Blog を書いているのですが、直接的にはこの Blog 記 事を書くきっかけとなったのは、以下の Google Cloud Blog です。
なお、上記 Google Cloud Blog の日本語抄訳版はこちらです。
単にこの Blog を紹介するだけでも良かったのですが、もうちょっと具体的な手順や考慮点も含めてまとめてみたら有用かも、と思い書いたのがこの Medium Blog となります。ぜひ合わせて両方お読み頂ければと思います。また、最後に Google Cloud Blog で紹介されている構成例についても確認していきます。
■TL;DR
- Traffic Director はマネージドサービスだし、制御対象となる Envoy は、GCE インスタンスにオプション1つで展開できるので、ほぼ構築作業は不要。
- Traffic Director を使ったトラフィックルーティングは、コンテナじゃなくても、マイクロサービスじゃなくても、便利。
- Traffic Director は、GCVE などを使った従来のアプリケーションをクラウドネイティブへの道へと進める第一歩としては最適、かも。
■GCE であっても、GCVE であっても、Google Cloud らしく使う
Google Cloud で仮想マシンを使うことができるサービスとしては、Google Compute Engine (GCE) と Google Cloud VMware Engine (GCVE) があります。どちらも Windows や Linux などのゲストOSを実行するVM環境を提供するという意味では同じ様なサービスですが、併存して提供されていることからも分かる通り、色々な意味で GCE と GCVE は異なるソリューションであり、その特徴や使い勝手は異なります。
GCE と GCVE の違いについては、2022年4月に開催された Google Cloud Day の中で私が行ったセッション『あなたのそのサーバ、 Google Cloud にしてみませんか? 〜IaaS として Google Cloud を活用する方法〜』の中で詳しく触れていますので、興味がある方はぜひ録画および資料を御覧ください。
お客さまが VM の実行環境として GCVE を選択される理由は様々ですが、『オンプレミスからのクラウドマイグレーションにおいて、最小限の移行コストと移行期間で移行したい』であったり『様々な理由でOS環境をアップグレードできない』などの理由が多くあるケースです。
GCVE は Google Cloud の中で VMware vSphere を実行するサービスであり、HCX を用いたオンプレミス環境などとの間でのネットワークの L2 延伸もサポートされていますので、オンプレミスの VMware からのクラウド移行において “VMとして一切手を入れない” ままでの移行ができたり、（サポートおよびセキュリティ的な課題はありますが）比較的レガシーな OS であっても動作が確認されていたり等、企業の社内システムを支えるサーバ群のクラウドへの移行の敷居を大きく下げてくれます。
その一方で、GCVE のプライベートクラウドは（自明ですが） VMware vSphere を利用していることに加えて、GCE を含む他の Google Cloud が共通で利用しているコンピューティングリソース基盤ではなく、お客さまに対して専有的に提供される物理サーバを ESXi として利用する専用環境が提供されること等、ソフトウェア的にもハードウェア構成的にも他の Google Cloud のサービスとは異なる特殊性があります。
また、GCVE のプライベートクラウドはお客さまの VPC との間ではプライベートサービス接続によって接続されます。プライベート IP アドレスで VPC 内の GCE インスタンスやオンプレミス環境との接続、さらには Cloud SQL を始めとした内部 IP アドレスで接続可能なサービスとの通信ができる点など、大半の使い勝手は GCE を利用する場合と大きな違いはありませんが、GCVE の VM に対しては GCE のインスタンスのように外部 IP アドレスを柔軟に紐付けたり Cloud NAT を利用したりすることはできないため、別途 GCVE 専用の Internet Gateway や Public IP Service が用意されている等、どうしても実装上の制約がある部分もあります。
しかし、GCVE の利点を活用して Google Cloud への移行を行った VM を使っているサービスの中にも、投資を継続することでさらにその先へと改善や最適化を進めていきたい対象もあるはずです。
たとえば、GCVE VM の上でモノリシックなアプリケーションとして作られていたサービスを、GCE の VM インスタンスへと移行したり、GKE や Cloud Run などを活用したマイクロサービスとして機能毎に切り出していったりなどによって、段階的なクラウドネイティブアプリケーション化を進めていきたい様なケースです。
このようなケースにおいては、ユーザに対するサービスを継続しながらもアプリケーションを支える仕組みを、段階的・継続的にマイグレーションしたり、モダナイズしたりすることとなります。そして、その際に必ず必要となる仕組みがロードバランサであり、今回のテーマである『GCVE の VM でも Cloud Load Balancing を使いたい！』につながります。
ユーザとサービスの間にロードバランサを挟み込むことによって、ロードバランサの本来の役割である負荷分散や可用性を実現するだけではなく、バックエンドを GCVE VM から GCE インスタンスへと段階的に移行していったり、ウェブサービスの特定パス範囲を GKE や Cloud Run を使ったマイクロサービスとして切り離してロードバランスしたりなどといった移行の手段としても活用することが可能となります。
■（まだ）一筋縄ではいかない GCVE VM に対する Cloud Load Balancing の利用
しかし『なるほど、では GCVE の VM を Cloud Load Balancing によるロードバランス先として構成しよう！』と考えたときに、Google Cloud の Cloud Load Balancing の仕様をご存じの方は『ん？』となります。Cloud Load Balancing では、バックエンドサービスとしてインスタンスグループもしくはネットワークエンドポイントグループ（NEG）を登録できます。
しかし、Google Cloud のネイティブなサービスである GCE のインスタンスの場合はインスタンスグループとして構成することは簡単にできますが、GCVE の VM は VMware vSphere 上で動作しているため、残念ながらインスタンスグループとして管理することはできません。では、NEG はどうかというと、NEG には様々な種類があり、その中の1つとして “ハイブリッド接続 NEG” というものがあり使えそうなのですが、2022年7月時点では GCVE の VM をハイブリッド接続 NEG として構成し、直接 Cloud Load Balancing の配下に入れて利用する構成はサポートされていません。
『あ〜ではどうすればいいの…』ということで登場するのが、おまたせしました!?、Traffic Director です。Traffic Director は、一言で言ってしまえば、Service Mesh のマネージドコントロールプレーンサービスです。マネージドサービスですので、お客さまご自身で展開と管理を行う必要がある Istio と比較して、Traffic Director の場合はコントロールプレーンは完全にマネージドサービスとして SLA に基づいて提供されますし、Traffic Director によって制御される Envoy のコンテナや GCE インスタンスへの展開も簡単に行うことができる仕組みが用意されています。
あれ？ Cloud Load Balancing と GCVE の話をしていたのに、なぜ唐突に Service Mesh が？と思われるかもしれませんが、最終的に使いたいのは Traffic Director によって制御された Envoy Proxy です。つまり、Envoy Proxy を Reverse Proxy として使用し、GCVE VM が提供するサービスを Envoy Proxy のバックエンドに配置する構成にして使おう、ということです。今回は、Envoy Proxy を GCE インスタンスに展開して利用する構成を使用します。
Traffic Director の詳細については、こちらのガイドを参照ください。
ちょっと情報が古くなってしまっている部分もありますが、この Google Cloud Japan Blog の中で同僚の Utchy こと内間さんが書かれている以下の Blog も参考になるかと思います。
Envoy はサイドカーとしてアプリケーション自身と同居させて使う方式が一般的ですが、今回の使い方では GCVE VM のゲストOS自身には一切手を入れず、あくまでも GCE インスタンス側に自動的に展開された Envoy に Reverse Proxy として通信を中継させるかたちで利用する構成とします。
もちろん、Traffic Director を使わずに、GCE インスタンスで Reverse Proxy を構成して利用することももちろん可能です。しかし、その様な構成とした場合には、Reverse Proxy それ自体の管理が必要となりますし、性能要件などで複数の Reverse Proxy を並べるような構成となった場合には管理が大変です。
まず、Traffic Director を使うことによって Service Mesh それ自体を構築したり管理したりする必要がまずなくなります。GCVE の VM に対する接続をロードバランスさせたいだけなのに「ではまず、Isito の構築を行いましょう」ではちょっとツライですよね。
さらに、Traffic Director によって管理される Envoy Proxy は gcloud コマンドのオプション1つで GCE VM インスタンスにも展開することができます。別に GKE などの Kubernetes で管理された Pod に対して Envoy Proxy を展開して利用することも可能ですが、今回は登場する要素を最小限にすることと、Cloud Load Balancing のバックエンドとしての紐付けをシンプルにするために、GCE VM に Envoy Proxy を展開する構成を使用することとしたいと思います。
■GCVE VM に対して Cloud Load Balancing を使えると、何が嬉しいのか
実際の構成手順について見ていく前に、GCVE VM の前段に Cloud Load Balancing を配置する構成が使えるとどんな嬉しさがあるのか、いくつか挙げてみたいと思います。
クラウドネイティブなL4もしくはL7のロードバランスサービスを利用できる
Traffic Director を活用した Cloud Load Balancing の利用では、Google Cloud が提供する全てのロードバランササービスを利用できます。外部向けサービスに限らず、内部向けのロードバランサでも利用できますので、社内システムであっても適用できます。
付随して、Cloud Armor や Cloud CDN なども利用できる
外部HTTP(S)ロードバランサの場合には、Cloud Load Balancing と一緒に組み合わせてご利用頂ける Cloud Armor や Cloud CDN などももちろんご利用いただけます。
他の Google Cloud サービスと同じ仕組みで管理できる
わざわざ Envoy Proxy を展開するインスタンスを MIG として構成し、Envoy Proxy を管理する Traffic Director の追加までをする最大の理由は、GCVE の VM を Google Cloud のサービスの中で特別な扱いを必要としないようにできる点でしょう。Traffic Director を使わなくても同様の構成は可能ですが、Traffic Director を用いることで最大限マネージドサービスを活用し、Envoy Proxy についても最小限の工数で展開・管理できる「仕組み」としての利用ができます。
GCVE の NSX の役割を L2 / L3 （および必要に応じて L2 延伸）のみとすることで管理性と拡張性を高めることができる
GCVE でご利用頂けるネットワーク仮想化ソリューションである NSX ではロードバランス機能もご利用いただけますが、機能が限定的であることと、ロードバランス機能が NSX での提供から ALB こと Advanced Load Balancer への移行が進められています。そうした状況において、NSX には L2 / L3 のステートレスな役割のみを担ってもらうことで構成をシンプルにすることができますし、ステートレスな処理のみであれば NSX のゲートウェイを Active / Active で利用することが可能となるなど、様々なメリットもあります。
段階的なアプリケーションのクラウドネイティブ化の実行がやりやすくなる
今回は Traffic Director によって制御された Envoy Proxy を単純なプロキシとしてのみ利用する構成としていますが、Envoy は非常に高機能なロードバランサであり、高度なトラフィックルーティングを構成頂けるサービスです。GCVE VM 上で実行されているモノリシックなアプリケーションから段階的に機能をマイクロサービスとして切り離していったり、接続要求の一部だけを新バージョンへと振り分ける Canary リリースなど、様々なアプリケーション要件に対応できます。たとえ現時点では1台だけの GCVE VM で提供しているサービスであっても、その前段に Traffic Director を挟み込むことによって、その後のバックエンド側の GCE や GKE、場合によってはさらに Cloud Run などへの変更や拡張も格段にやりやすくなります。
■Traffic Director の構成手順概要
では改めて、GCVE VM への通信を Reverse Proxy する Envoy を管理するために Traffic Director を利用するための構成手順をご紹介します。
基本的には、以下URLのガイド「ハイブリッド デプロイ用にネットワーク エッジ サービスを設定する」掲載の手順で構成頂けます。GCVE VM も VPC から見れば一種のプライベート接続された対象となるためです。
上記ページでは、Traffic Director を用いることで Cloud Load Balancing のロードバランシング先として Envoy Proxy が導入された GCE インスタンスを通じてオンプレミスサーバで動作するサービスを利用する方法について記載されていますが、VPC 範囲外の IP アドレスとポート番号を指定するという意味では GCVE VM の場合でも位置づけは全く同様です。
構成の前提となる事項は以下のとおりです。
- Envoy Proxy を導入した GCE インスタンスが trafficdirector.googleapis.com へアクセス可能な VPC の構成（Cloud NAT や PSC 等）
- Traffic Director API の有効化
- Cloud DNS API の有効化（今回の構成例の範囲においてはDNSによる名前解決は使用しませんが）
- 必要なIAM権限を持ったサービスアカウントの準備
詳細については、以下のガイドを参照して下さい。
上記に加えて、GCE インスタンスで Traffic Director によって管理される Envoy を自動展開して利用する手順については、以下のガイドに手順が掲載されています。
なお、GCVE プライベートクラウドと VPC との接続や、それに伴う DNS による名前解決の構成などについては構成済みであることを前提とします。
また、最終的なサービスを提供する GCVE VM 上のウェブサービスについては構成が済んでいることとしています。
今回の構成の流れは以下のとおりです。
- Envoy Proxy を展開・有効化する GCE インスタンスを展開するためのインスタンステンプレートを作成する
（gcloud コマンドで作成し、その際に “— service-proxy=enabled” オプションを付加する） - Envoy Proxy 用 GCE インスタンスによる Stateless MIG を作成する
（動作確認をシンプルにするため、オートスケールは無効として1台のみのMIGとして構成する） - GCVE VM の IP アドレスとポート番号に基づいて、ハイブリッド接続 NEG を作成する
- Traffic Director 用のヘルスチェックを作成する
- Traffic Director 用のバックエンドサービスを作成する
- Traffic Director 用のルーティングマップを作成する
※ここまでの構成で、Envoy Proxy として展開された GCE インスタンスのポートにアクセスすることで GCVE VM 上で動作するウェブサービスへのアクセスが可能となります。 - Cloud Load Balancing で適切なロードバランサを指定して構成し、バックエンドサービスとして Envoy Proxy 用 GCE インスタンスで構成される MIG を指定する
- Cloud Load Balancing 経由で接続し、問題がないことを確認する
今回はテストに含めませんが、Cloud Load Balancing のロードバランサとして外部 HTTP(S) ロードバランサを構成した場合には、それと組み合わせて Cloud Armor によるWAFや、Cloud CDN によるコンテンツキャッシュ、IAP を用いた reCAPTCHA 認証などを組み合わせてご利用頂けるようになります。
■構成例
1. Envoy Proxy を展開・有効化する GCE インスタンスを展開するためのインスタンステンプレートを作成する
（gcloud コマンドで作成し、その際に “ — service-proxy=enabled” オプションを付加する）
下記は、td-vm-template-auto-v3 という名前のインスタンステンプレートを sample_project に作成する例です。また、Traffic Director が使用する権限を設定したサービスアカウント tdclient@sample-project.iam.gserviceaccount.com を作成済であることを前提としています。この例では Debian 11 を使用していますが、CentOS や RHEL、Ubuntu などを利用することも可能です。また、今回は Envoy 自身には外部IPは割り当てないため、 “ — network-interface=” で 内部IPを紐付けるSubnet指定に続けて no-address を指定しています。一番重要な点は “ — service-proxy=enabled” オプションを付加することで、このインスタンスに対して Traffic Director で管理される Envoy Proxy の展開を指定している点です。
gcloud compute instance-templates create td-vm-template-auto-v3 \
— project=sample_project \
— network-interface=subnet=subnet-name,no-address \
— service-account=tdclient@sample-project.iam.gserviceaccount.com \
— region=asia-northeast1 \
— image-family=debian-11 \
— image-project=debian-cloud \
— service-proxy=enabledなお、今回は最小限のオプションのみを利用していますが、実際には Envoy を構成する GCE インスタンスの展開時には様々なオプションを付加することが可能です。詳細については以下の URL を参照して下さい。
2. Envoy Proxy 用 GCE インスタンスによる Stateless MIG を作成する（今回の例では “td-vm-mig-asia-northeast1” という MIG を作成）
（動作確認をシンプルにするため、オートスケールは無効として1台のみのMIGとして構成しています）
gcloud compute instance-groups managed create td-vm-mig-asia-northeast1 \
— zone=asia-northeast1 \
— template=td-vm-template-auto-v3 \
— size=1
3. GCVE VM の IP アドレスとポート番号に基づいて、ハイブリッド接続 NEG を作成する（今回の例では “td-test-neg1” という NEG を作成）
gcloud compute network-endpoint-groups create td-test-neg1 \
— network-endpoint-type=non-gcp-private-ip-port \
— zone=asia-northeast1-b今回の例では、Web サービスを提供する GCVE VM の IP アドレスは 10.1.8.3 で 80 番ポートで http ベースで接続を受け付けているとします。
gcloud compute network-endpoint-groups update td-test-neg1 \
— zone=asia-northeast1-b \
— add-endpoint=”ip=10.1.8.3,port=80"
なお参考までに、この構成例では 10.1.8.3 に対して http 接続すると以下の様なレスポンスが返される構成を利用しています。
4. Traffic Director 用のヘルスチェックを作成する（今回の例では “td-test-health-check1” というヘルスチェックを作成）
gcloud compute health-checks create http td-test-health-check1
5. Traffic Director 用のバックエンドサービスを作成する（今回の例では “td-test-backend-service1” というバックエンドサービスを作成）
Traffic Director 用のバックエンドサービスの場合には、負荷分散方式として “INTERNAL_SELF_MANAGED” を指定します。また、パラメータの中で 4. で作成したヘルスチェックを指定します。
gcloud compute backend-services create td-test-backend-service1 \
— global \
— load-balancing-scheme=INTERNAL_SELF_MANAGED \
— health-checks=td-test-health-check1作成したバックエンドサービスに、3. で作成したハイブリッド接続 NEG を紐付けます
gcloud compute backend-services add-backend td-test-backend-service1 \
— global \
— network-endpoint-group=td-test-neg1 \
— network-endpoint-group-zone=asia-northeast1-b \
— balancing-mode=RATE \
— max-rate-per-endpoint=56. Traffic Director 用のルーティングマップを作成する（今回の例では “td-hybrid-forwarding-rule” というルーティングマップを作成）
以下は、Traffic Director を利用する場合におけるルーティングマップの概要図です。今回は 5. で構成した NEG をバックエンドとする構成としますが、もちろん Traffic Director でもバックエンドに MIG を利用する構成も可能です。
まず、URL マップを作成します。
gcloud compute url-maps create td-hybrid-url-map \
— default-service=td-test-backend-service1Envoy に対して Proxy 動作をさせるための定義を YAML ファイルで作成します。今回の例では、target_proxy.yaml というファイル名で、Proxy としての動作に必要な最小限のパラメータのみを定義した YAML ファイルを使用します。
name: td-hybrid-proxy
proxyBind: true
urlMap: global/urlMaps/td-hybrid-url-map作成した YAML ファイルをインポートしてターゲット HTTP プロキシを作成します。今回の例では、target_proxy.yaml ファイルが gcloud コマンドの実行パスに存在する場合となっています。
gcloud compute target-http-proxies import td-hybrid-proxy \
— source=target_proxy.yamlこのターゲット HTTP プロキシを参照する転送ルールを作成します。構成可能な転送ルールのプロパティはこちらを御覧ください。
転送ルールの IP アドレスを 0.0.0.0 とする理由は、target_proxy.yaml ファイルで “proxyBind: true” としている場合には 0.0.0.0 のみがサポートされることとなるためですが、これにより、HTTP リクエストで指定されていた IP アドレスは無視され、ポート番号やホスト名、URL マップの指定に基づいてトラフィックルーティングが行われます。
また、今回はあえて待ち受けるポート番号を 8080 としてみることで、Traffic Director によって Web アプリケーションへの通信が Proxy されていることを明確にしてみました。
gcloud compute forwarding-rules create td-hybrid-forwarding-rule \
— global \
— load-balancing-scheme=INTERNAL_SELF_MANAGED \
— address=0.0.0.0 \
— target-http-proxy=td-hybrid-proxy \
— ports=8080 \
— network=sample-vpcこの時点で、Envoy Proxy が展開された MIG のインスタンスの IP アドレス 10.0.1.29 に対して http://10.0.1.29:8080 のようにブラウザでアクセスすると、バックエンドサービスとして指定された GCVE VM 側のウェブサービス画面が表示されることを確認できます。
7. Cloud Load Balancing で適切なロードバランサを指定して構成し、バックエンドサービスとして Envoy Proxy 用 GCE インスタンスで構成される MIG（今回の例では、“td-vm-mig-asia-northeast1” という MIG）を指定する
8. Cloud Load Balancing 経由で接続し、問題がないことを確認する
今回は Cloud Load Balancing の構成手順については本題ではないため割愛しますが、当然ながら Cloud Load Balancing のバックエンドサービスとして Envoy Proxy を展開する MIG を指定することで、問題なくロードバランサと Envoy Proxy を経由して GCVE VM の Webサービスへの接続できます。
下記例は、内部HTTP(S)ロードバランサを構成し、ロードバランサのIPアドレスとして 10.0.1.51 を割り当てた構成において、バックエンドサービスに Envoy Proxy の MIG を登録してアクセスしてみた結果です。ロードバランサから Envoy Proxy を経由して GCVE VM からの応答が返されていることが確認できます。また、ロードバランサのフロントエンドは 80 番ポートに構成しましたので、ポート番号の指定をしていないことも確認できます。
Envoy Proxy 用 MIG のインスタンス数や、ハイブリッド接続 NEG に紐付ける IP アドレスとポート番号の組み合わせ等は、もちろんいずれも追加や削除が可能です。ただし、Cloud Load Balancing の場合と異なり、Traffic Director の場合はバックエンドサービスとして複数の種類のバックエンド（MIG と NEG など）を含めることはできません。なお、URL マップとして異なるバックエンドサービスを解決するルールを定義することは可能です。
■まとめ：Blog で紹介されている構成例を確認する
最後にまとめとして、冒頭で紹介した Google Cloud Blog で紹介されていた構成例を見ていきたいと思います。
Scenario #1 — External load balancer
外部 HTTP(S) ロードバランサのバックエンドサービスとしては Envoy Proxy インスタンスを指定し、そこからさらに通信をハイブリッド接続 NEG として IP アドレスとポート番号で指定された GCVE VM に対して Reverse Proxy することで VPC 側の Internet 接続を利用して外部へのサービス提供が可能です。先述の通り、この構成の場合には Cloud CDN および Cloud Armor を利用することも可能です。この図では Envoy Proxy の役割を担っている GCE インスタンスが1台だけですが、もちろんこのインスタンスは MIG として管理されていますので、負荷などに応じて自動的にスケールアウト・スケールインさせることが可能です。
このシナリオについては、別パターンとして Envoy Proxy からの通信の振り先を GCVE 側の NSX の Tier-1 ゲートウェイに構成した NSX LB の VIP とする構成も示されていますが、通信に関連する要素が増えてしまう点に加え、NSX LB が L4 レベルのロードバランスしかできない点や将来的に NSX の LB 機能が Advanced Load Balancer (ALB) へと移行されていることが予定されていることから考えると、あまりこの構成での利用は推奨されないと思います。
ブログ記事内にも書かれていますが、通信要件が HTTP(S) 以外である場合には、外部 TCP/UDP ロードバランサや TCP プロキシロードバランサ などを利用することも可能です。
Scenario #2 — Internal load balancer
内部 HTTP(S) ロードバランサを用いることも、もちろん可能です（というか、このブログ内で同じ構成を作ってみていますね）。Envoy Proxy 自身がバックエンドサービスに対するいわばロードバランサとして動作していますが、Envoy Proxy が動作する GCE インスタンス自体の可用性やアップデート時の接続性の確保などを考慮すると、内部通信であってもロードバランサを経由させることにはメリットがあります。
こちらの構成についても、NSX LB を経由させるパターンも紹介されていますが…そこは割愛します。
Traffic Director はコンテナのために使われることが一般的かもしれませんが、GCE インスタンスに対しても簡単に Envoy を展開し制御できることを活用して、一切コンテナを使っていない場合であっても高機能なトラフィックルーティングを簡単に利用するための仕組みとして GCE インスタンス、そして GCVE VM などを使ってサービス基盤を構成している場合においても組み合わせてご利用頂けるサービスです。
特に GCVE VM を利用している場合において、今回紹介した Traffic Director によって Cloud Load Balancing を始めとした Google Cloud の各種サービスとのより密な連携により、オンプレミスではできなかった、もしくは困難であったよりクラウド的な使い方を検討するきっかけになれば嬉しいです。
そして最後に、今回の Blog のタイトルを『GCVE の VM でも Cloud Load Balancing を使いたい！ — Traffic Director 編』としている所には、色々な期待をこめています。次回、新たな xxx 編 をお届けできることを楽しみしています！
下書きの段階でとても有益なコメントや助言を頂いた皆様（特に、Utchy-san, Seji-san ) ありがとうございました!!
