GCP

編集

クラウド

免責事項

  • このページを書いているのは、グーグル・クラウド・ジャパン合同会社に所属するTechnical Solution Engineerの若田部 亮です(2019 4月-)。
  • 本ページに書かれていることは個人的なメモであり、Alphabet傘下の会社の意見とは異なりますので、ご了承ください。

概要

  • GCPの使い方

目次

強み

  • 10億人が利用するサービスのインフラをそのまま借りれる
  • Anthosでマルチクラウドが簡単
  • Google!

疑問

  • KVS
  • 可用性と可用性の指標
  • ハイパーバイザー

ログイン

# まずこれをやる
gcloud auth login

# 次にこれを走らせる
p=project-name # プロジェクト名
gcloud config configurations create inspect-$p
gcloud config configurations activate $p
gcloud config set core/project $p
gcloud config set billing/quota_project LEGACY
gcloud config set account wakataberyo@google.com
gcloud projects describe $p

基本構成

  • 物理的には、リージョン->ゾーン->物理サーバとなっている

  • プロジェクトはリージョンに対して割り当てられている。

    • リージョン内ではゾーンで冗長化されている

  • プロジェクト

    • 唯一の課金アカウントと結び付けられている
    • プロジェクトには一般アカウントが複数ログインできる
    • 逆に、それぞれの一般アカウントは、複数のプロジェクトにログインできる
    • プロジェクトの権限管理はIAMとかいうものでなされる（なんの略？）
    • 複数のインスタンス=サービス=VMみたいなものが、一つのプロジェクトの中で、ネットワークを構成して動いている。インスタンスそのものが別のリージョンで動いていたとしても、内部ネットワークとして利用できる

  • プロジェクトのネットワーク

    • Legacy Network = リージョンにまたがったsubnet
    • Subnet Network = 単一のリージョンでのsubnet

  • Cloud Shell

    • f1-microクラス/debianのめちゃくちゃ弱いGCEの一時インスタンスの上で実行されるシェル
    • 課金なし・永続5GB, ユーザごとに割り当てられていて、プロジェクトにまたがって共有される

用語

  • Cloud Launcher

    • 150個以上の事前ソフトパッケージをGCEにデプロイできる

  • CAPの定理

    • NoSQLで3つの性質を同時に満たすことが極めて難しいという定理

  • デプロイ

一般的なクラウドサービスの知識

  • 仮想化技術

    • ホスト型仮想化: 要するにVM, 手軽だがオーバーヘッドが高い
    • ハイパーバイザー型仮想化: GCEではLinuxKVMが使用されている (GCEはこれが使われている)
    • コンテナ型仮想化: 動作環境（ライブラリなど）を閉じ込めて、見た目独立したサーバのように動作するサービス

  • ライフマイグレーション技術

    • ハードウェアメンテンナンスのときに、「あるVM in サーバAを、in サーバBに無停止で移動する」

  • プリエンティティブVM

    • いつ切られてもおかしくないVMだが、80%割引

  • ディスク

    • 永続ディスク: ネットを介して接続されたNASみたいなもの。
    • ローカルSSD: めちゃくちゃ早い(IOPSが高いという)

  • Web三層アーキテクチャ

    • Webフロントサーバ： HTTP reqを受け取って、HTTP resを返すためのサーバ
    • Webアプリケーションサーバ: 本体の実行
    • データベースサーバ: データの管理をする、ボトルネックになりがち
    • 小規模システムでは上記をすべて兼ねることもできるし、WebフロントとWebアプリケーションを兼ねることもある（p55-58参照）

基本

REST API

  • Google API を REST で叩く方法 https://googleapis.github.io/HowToREST.html
    • Google Cloud Console > Credentials page に行き、APIキーを作る
    • Cloud Shell で GOOGLE_API_KEY=[KEY]とする。
    • 以下のように POST を送ることで、Language API でスペイン語だと分析される。
curl "~~https://language.googleapis.com/v1/documents:analyzeEntities~~ (リンク切れ)" \
  -X POST \
  -H "X-Goog-Api-Key: $GOOGLE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"document":{"content":"The rain in Spain stays mainly in the plain.", "type":"PLAIN_TEXT"}}' \
  -i
  • REST & CMD LINE で Listing datasets (リンク切れ) をしようすると、
curl -X GET \

-H "Authorization: Bearer "$(gcloud auth application-default print-access-token) \

~~https://automl.googleapis.com/v1/projects/[PROJECT~~ (リンク切れ)]/locations/us-central1/datasets

に対して、以下のエラーが返る。

"code": 403,
"message": "Your application has authenticated using end user credentials from the Google Cloud SDK or Google Cloud Shell which are not supported by the automl.googleapis.com. We recommend configuring the billing/quota_project setting in gcloud or using a service account through the auth/impersonate_service_account setting. For more information about service accounts and how to use them in your application, see https://cloud.google.com/docs/authentication/.",

この場合、サービスアカウントの JSON Keyを使う必要がある。

かと思って Google API Key を使うと、OAuth2 を使えと言われる。何の差なんだ…

curl "~~https://automl.googleapis.com/v1/projects/[PROJECT~~ (リンク切れ)]/locations/us-central1/datasets" -X GET -H "X-Goog-Api-Key: $GOOGLE_API_KEY"
{
  "error": {
    "code": 401,
    "message": "Request is missing required authentication credential. Expected OAuth 2 access token, login cookie or other valid authentication credential. See ~~https://developers.google.com/identity/sign-in/web/devconsole-project.~~ (リンク切れ)",
    "status": "UNAUTHENTICATED"
  }
}

サービス

L7リバースプロキシ

dispatch.yaml や dispatch.xml はGoogle App Engine(以下GAE)のFrontendでルールベースでL7 HTTP Reverse Proxyしてくれるものです。 これはMicroservicesをやる上では大変便利なものになっています。 L7リバースプロキシなので、全てのサービスが立ち上がっている状態じゃないとデプロイできない（してもいいけどない）

Google App Engine Standard

  • Standardはmem,cpuなどいろいろ見るが、FlexはCPUのみ。

  • GAEのserviceは、yamlにservice: service_nameというのがあれば、サービスが建てられる。一方で、app.yamlには通常serviceの行が存在しないので、defaultというサービスが建てられる。サービスがworkerの場合https://worker-dot-wakataberyo-sandbox2.appspot.com/のように、[service-name (リンク切れ)]-dot-[project name].appshot.comの名前でアクセスできるっぽい？

  • warmupリクエスト

    • オートスケーリングしているので、インスタンスのスタートアップ時にMemcacheはちゃんと整っていないし、インスタンスのメモリ上に必要なデータが揃っていない可能性がある。
    • そこで、インスタンスを作ってリクエストが車での間に前処理を済ませておこうというのがこのwarmupリクエスト。
    • これをオンにしておくと、リクエストが着終わってからインスタンスを作るのではなく、予測的にインスタンスを作るのですこし高くなるらしい。

GAE Standard, GAE Flex

  • Google App Engine

  • .gcloudignoreによってデプロイのときにアップロードするファイルを限定できる。

  • deployをするとversionが一つ増える。

    • Flexはインスタンスが一つ以上あるので、GAE->Versionが増える。Flexはinstanceが1個以上必要なので、VMインスタンスが一つは残って課金されるので、適宜消していったほうが良いという話が書いてあった。

  • GAE サービス間認証は IAP か token を使ってやる

    • https://medium.com/google-cloud-jp/gae-2nd-gen-%E3%81%A7%E3%81%AE%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E9%96%93%E8%AA%8D%E8%A8%BC-1ed1d8b1abce
    • GAE 1st-gen では X-Appengine-Inbound-Appid ヘッダという魔法のヘッダがありました。このヘッダは URLFetch を使用して別の --GAE サービスにアクセスする時に、GCP が自動で呼び出し元の Project ID を入れてくれるヘッダです。そのため呼び出し元の Project ID が自身の Project ID と同一かどうかを調べるだけで認証できました。
    • しかし GAE 2nd-gen では App Engine API がサポートされていないため、URLFetch API も使えず、X-Appengine-Inbound-Appid ヘッダも付かなくなりました。そのため 2nd-gen に移行するためには代替となる認証方法が求められています。

Task Queue

Task QueueはCloud TasksとPub/Subの中間みたいなもの。PushQueueとPullQueueという2種類のキューがあって、使い分ける感じ。 To use the push Task Queue service outside of the first generation standard environment, you can use Cloud Tasks. In many cases where you might use pull queues, such as queuing up tasks or messages that will be pulled and processed by separate workers, Cloud Pub/Sub can be a good alternative as it offers similar functionality and delivery guarantees. デフォでdefaultのqueueがあるらしい。これは5/s rateのPush queue。Push quueeとかでも、最大レートやリトライ回数などを細かく指定し、名前を浸かるためのものがquuee.yaml(GAE Standardのみ)

Firebase

企業がソーシャルログインを導入するメリット ソーシャルログインの導入で企業が得られるメリットは、ユーザーが得られるメリットを逆の視点から見たものになります。 会員登録時の離脱率が減る 詳しいユーザー情報を得られる（※SNSプロバイダによる） 再訪率が上がる パスワード再発行やログインできないという問い合わせが減る セキュリティ対策へのコストが減らせる

Facebook、Twitter、Instagramが利用するようなOAuth2の仕様は、やや独自仕様になっている傾向があります。このような手間をoauth.ioを使うことで、簡単にSNSを用いた登録ボタンを作成できます。

Firestore

  • Document型データベース Firebase Realtime Database = Cloud Firestore in Native Mode Cloud Firestore in Datastore Mode Datastore

Firestoreには、ネイティブモードとDatastoreモードの二種類があり、どちらか一方しか選ぶことしかできません。 ネイティブモードは、簡単に言うとFirebase Realtime Databaseの機能が使えるモードです。 Datastoreモードは、その名前のとおり、FirestoreのストレージレイヤでDatastoreのシステム動作するモードです。（正確にはDatastoreモードがDatastoreの後継です。） Firestoreとして一括りにされる傾向が強い印象ですが、DatastoreモードではFirestoreの主な機能であるリアルタイム機能が使えなかったりするなど、Firestoreと言ってもまるで別のサービスと考えた方が良いと思います。

Firestore for realtimeという全然違うものがあるらしい。

Memstore

  • Redis

    • an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker.
    • 基本的なデータ構造を扱えるNoSQL データベース
    • セッション管理・カウント・ランキングなどの実装に使うのがよい。RedisはI/Oの速さが長所で、消失してもダメージが少ないが、大量アクセスが見込まれるような、ゲームコンテンツなどで使用すると、高い効果を発揮できると思います。
    • あと、パブサブ・メッセージキュー・ロックとしても使うことができるらしい。すごい

  • メモリ上に全部データを乗せるかなりドラスティックなデータベース

    • スナップショットというものがあって、これを使うと非同期でRDBダンプによってディスクに書き込まれる
    • 2秒おきにデータをファイルシステムに書き込むようになっているので、必要であれば安全なオプションを利用可能。
    • 何がmemcachedと違うのかというと、データを2通りの方法でディスクに書き出せるというところ。

  • SQLと違ってシングルスレッドに限定されているので自動的に排他的（memcachedはマルチスレッドで処理可能）

    • メモリを使い果たしたら、LRUなどのルールから削除していく。注意点としては、Radisの設定を「データ削除しない」にしておくと、メモリが足りなくなったときに削除せずに、書き込みエラーになる
    • Radisで落ちてほしくないならばちゃんとメモリ増設をする。本当にmaxmemoryもttlも設定していないと、OOMで殺されるので注意
    • 古いVerは爆弾を抱えていることもあるので、理由もなく使い続けるのはやめよう。
    • ログとかも、新しいVerの方が色々吐いてくれたりするので、問題発生時の原因特定がしやすい。

  • maxmemoryと書いてあるけど、これはevictする閾値なので、これ以上のメモリを消費することもある。なので、メモリ性費用を厳密に制限することはできない。2~3倍メモリを消費することくらい全然ありえる。

    • イメージバックアップは10000回keyの書き換えが会ったら60秒後にディスクに保存するみたいなやつ
    • まずoutput-bufferってなんやねん、という話から。
    • output-bufferはRedisがメモリ上に確保するバッファの一種。
    • レプリケーション環境で運用してる際、slaveはmasterのコピーであるので、keyの削除時には「このkey消しといてー」とslaveに通知する必要がある。
    • その情報はoutput bufferにため込んで、まとめて送信される。
    • あまりに削除するkeyが多かったり、masterが抱えるslaveがたくさんあったりすると、output bufferの分だけ、メモリを大量に消費してしまう。
    • そうすると、通信がいつまで経っても終わらなくなって、しかし削除要求は増え続け、slaveの更新ができないまま、メモリ消費量だけ肥大化する。
    • こうなると非常に危険で、色々な問題を誘発することがある。
    • 空きメモリが無くなって、HTTPが死んだり、前述のBGSAVEプロセス作成に失敗して
    • スナップショットが長期間保存されない状況になったりする。

  • Radisはバージョンを上げるのはマジで大切

  • あとRadisは一つに丸投げするのではなく、インスタンスを風数に分ける必要がある。

    • appendfsync everysecというのがあって、これをonにしておくと書き込み操作のたびにfsyncする。ちなみにeverysecではなくalwaysというのがあり、これが一番安全

  • client-output-buffer-limitは所定の容量をbufferが超えたら、

    • クライアントとの通信を強制的に切断するという設定。
    • これはこれで問題があるけど、メモリが枯渇するよりはマシかもしれない。
    • masterから見たクライアントというのは、slaveのことなので仮にbufferのピーク容量が500MBで、slaveが4台繋がってたら、最大で2GBぐらい消費することになる。
    • 実際は詰まり始めたらどんどん消費してしまうので、「最大で」とか「最悪でも」なんて
    • 想定をしても、あまり意味はないかもしれない。
    • ただ、output-bufferの危険性を認識しておくのは非常に大事。
    • 最終的にはサーバ内のディスクにデータが保存されますが、保存直後はメモリに一時保存されるため、データ揮発の可能性はゼロではありません。
    • バックグラウンド書き込み用のメモリをどれくらい確保すればよいかと言うと、2.8.22 以降の場合は 25 (25 パーセント) に設定、それ以前なら50%にする必要がある
    • active deflagという機能が4.0から提供されていてこれを使うと効率的にメモリを使えるようになる（が完全な解決ではない）

Memcacheというものは、データがいつか消えてしまうかもしれないhash関数。Storageにアクセスするのに比べたら圧倒的に早いのが特徴。これって各インスタンスごとに定義されると思っていい？それとも全インスタンスで共有？ 制限時間を設定することもできる（当然保証はできないけど） memcache は他の一時的な値にも便利です。ただし、memcache のみに値を保存し、他の永続ストレージを使用しないかどうかを検討する場合、値が突然使用できなくなったときに、アプリケーションが適切に動作するようにしてください。 新しくできたインスタンスのためにmemcacheを用意しようみたいな話があるので、おそらくはmemcacheはインスタンスワイズの話なんだろうなあと思う

Dialogflow

言語解析エンジン 音声入力で問題となりやすい自然言語の解析を簡単にやってくれる機能。 これを挟むことで言語解析のややこしいところを大幅に削減できる。

Google Compute Engine (GCE)

  • GCEのホストマシンが死んだりメンテに入った場合（プリエンプティぶも含む）

  • managed instance-groupにはautohealingという機能がある。

    • 文字通り、ヘルスチェックの結果によってインスタンスを自動修復(再作成)する機能だ。
    • 負荷分散におけるヘルスチェックは、ロードバランサの振り先がHEALTHYかどうかを見るだけで、インスタンスの再作成は行わないが、マネージドインスタンスグループに適用されるヘルスチェックはインスタンスがUNHEALTHYになったら、削除して再作成する。

  • マネージド インスタンス グループ（MIG）

    • マネージド インスタンス グループ（MIG）は、ステートレスのサービス提供側のワークロード（ウェブサイト フロントエンドなど）や、高性能または高スループットのバッチ処理用コンピューティング ワークロード（キューからの画像処理など）に適しています。
    • まじ！競プロに使えそう

  • プリエンプティブインスタンスを一日立てて落とされる確率は結構低い。僕が試したときは2%くらいだった。

  • これを使うとCloud FunctionsでGCEをシャットダウンさせるコードが書いてある

計算機用としての利用

  • cpu/memを簡単にいじれるので非常に便利
  • 計算が終わったら sudo shutdown -h now で自滅できる
  • データの吸い出しはどうすればよい？(TODO コマンドをここにかく)

GCF

  • GCFは、イベントドリブンな処理

    • HTTPリクエストで超マイクロサービスを作るとき（素数判定とか）
    • GCSがアップロードされたら検知して何か作業するとき
    • pubsubに何かがパブリッシュされたとき

  • 例

    • GCFを使ってGoogle Cloud Storage (GCS)のファイルを自動で圧縮するみたいなやつ。BUD（マイクラ用語）だね

  • pubsubの構成要素

    • publisher
    • topic
    • subscription
    • subscriber

  • topic 1:many subscription 1:1 subscriber

    • 複数のsubscriberがいるならば、それぞれに対してtopicを設定する必要がある。
    • subscriptionはデフォルトではpullで、pushにしたければ、自分の有効なエンドポイントをAPIで教えてあげる必要がある。pullの場合、10秒で再送信受け取りをする必要がある。
    • APIとしては、たとえばあるtopicに紐付けられたsubscriptionを全列挙するなどもできる

  • Subscriber には push か pull があって、pushだと subscription から POST が投げつけられる

  • API的には、以下のようにトピックやサブスクリプションを指定できる。トピックはpublisherが知らせるところ、subscriptionは一つのsubscriberがpullするところ。

    • projects/project-identifier/[topics/subscriptions]/relative-name
    • project-identifier は、Google Cloud Platform Console から取得可能なプロジェクト ID にする必要があります。例: projects/myproject/topics/mytopic

GCFとかを温めておくためには、定期的にpingするくらいしか方法がないらしい。 https://stackoverflow.com/questions/51782742/how-can-i-keep-google-cloud-functions-warm

Datastore

  • Keyにはidもしくはnameがつけられている。idはLongでnameはString

  • Datastore の特徴

    • スケールする & 遅くない & そこそこ柔軟な検索ができる
    • バランスがいいので、逆にハマる

  • 非自明な制約

    • 1 回の commit に同じエンティティ（キーが同一のエンティティ）を複数回含めないでください。1 回の commit に同じエンティティを複数回含めると、Cloud Datastore のレイテンシに影響する場合があります。
    • クエリ結果のキーだけにアクセスする場合は、キーのみのクエリを使用します。キーのみのクエリでは、エンティティ全体を取得する場合よりも低いレイテンシとコストで結果が返されます。

  • 射影クエリ

    • 要するにSQLのselectで一部だけ撮ってくるみたいなやつ
    • エンティティの特定のプロパティだけにアクセスする場合は、射影クエリを使用します。射影クエリでは、エンティティ全体を取得する場合よりも低いレイテンシとコストで結果が返されます。
    • 多くの場合、アプリケーションが必要とするのはエンティティのプロパティの一部分だけです。 射影クエリを使用すると、エンティティのプロパティの中で本当に必要なものだけをクエリできるため、エンティティ全体を取得する場合よりもレイテンシとコストを低く抑えられます。
    • 射影クエリで指定するプロパティには、インデックスが必要です。

  • カーソル、制限、オフセット

    • クエリに対して制限を指定することで、1 バッチで返される結果の最大数を制御できます。次の例では、最大で 5 つの Task エンティティを取得します。
    • これによって、100万人のうち200000-2000100人を撮ってくる、みたいな処理をオーバヘッドなしでおこなえる。課金もされない。
    • 同じような機能をオフセットで行うことができるが、計算量的に悪いし遅いし課金される。Datastore モードのデータベースでは整数のオフセットをサポートしていますが、使用は避けてカーソルを使用

  • この記事がめちゃくちゃ面白い

  • これがめちゃくちゃよいエンティティグループの解説

    • 結局のところ、やっぱり連結されていれば全部強整合性を保つため、1op/sの制限がかかってかなりヤバい。組織全体で木にするというよりは、本当に強性合成が必要だと思ったところだけを木にして連結させるという発想のほうが良い。安心（強整合性）は高いということを知れ。

  • 重要な問題の 1 つは、各エンティティ グループに更新（またはトランザクション）の回数を保管するようにシステムを設計する必要があること

    • エンティティ グループごとに 1 秒間に 1 回の更新に制限されます[2]。 更新の回数がこの制限を超える必要がある場合、そのエンティティ グループはパフォーマンスのボトルネックとなるおそれがあります。
    • 上記の例では、各組織内のどの人のレコードも更新が必要になる可能性があります。
    • 「ateam」内に 1,000 人含まれていて、それぞれの人物のいずれかのプロパティを 1 秒間に 1 回更新する可能性があるとします。その結果、このエンティティ グループでは 1 秒間に最大 1,000 回の更新がありえますが、これは更新の制限により実現できません。
    • これにより、パフォーマンス要件を考慮した適切なエンティティ グループの設計の選択が重要であることがわかります。これは、結果整合性と強整合性の最適なバランスを求める際の課題の 1 つです。

  • 読み取り、書き込み、削除には、単一のオペレーションではなくバッチ オペレーションを使用します。

    • バッチ オペレーションでは、単一オペレーションと同じオーバーヘッドで複数のオペレーションが実行されるため効率的です。
    • トランザクションが失敗した場合はロールバックを試行してください。
    • 可能な場合は、同期呼び出しではなく非同期呼び出しを使用

  • Datastoreのデータ構造

    • 森がある。全ての頂点には必ず、キーと呼ばれる数字もしくは文字列が書き込まれおり、何らかの色が塗られている。
    • 各頂点には、数字もしくは文字列の任意長のタプルが書かれている。以下のクエリを高速に行え。
      • (1) 色を一つ選んで、同じ色のものを全列挙する
      • (2) 頂点を一つ選んで、その頂点を根とする部分木に含まれる頂点を全列挙する

  • https://cloud.google.com/appengine/docs/standard/python/datastore/transactions

    • Databaseでキーをランダムではなく文字列で管理している場合、同じ文字列 ID を持つエンティティを別のユーザーが作成または更新しようとする状況を処理するには、前の例と同様、ここでもトランザクションが必要です。
    • トランザクションを使用しない場合は、エンティティがまだ存在していない時点で 2 人のユーザーが同時にこれを作成しようとすると、1 人目のユーザーが知らないうちに 2 人目のユーザーが作成したエンティティが 1 人目のエンティティを上書きしてしまいます。
    • トランザクションのもう 1 つの一般的な用法は、名前付きキーによってエンティティを取得することです。名前付きキーがまだ存在しない場合は、新規に作成します。
    • 実はキーに対応する実態がなくても大丈夫（Noteに人のIDを突っ込んでputしていないし、実際にconsoleでみるとそれはないみたいな）

  • HTTPリクエストから来ているやつらは基本的に文字列だから注意！！！

    • Keyはnameだったりidだったりするので、とくにidの場合キャストせずに突っ込むとまずい。

  • ndbのkeyを作るときは、kindを文字列としても渡しても良いし、ndbのEntityのクラスを渡してもよいらしい。

sandy_key = ndb.Key(Account, 'sandy@example.com')
ndb.Key('Account', 'sandy@example.com', 'Message', 123, 'Revision', '1')

  • Keyを得るためには、これは本当に(S, S cup N)+の配列なので、自分で構築してしまったほうが早い。Keyはちゃんと設計して自分で作るもの。Entityから得るものというよりは。なのでfrom_pathを使っている時点でなんかおかしいと思ったほうが良さそう。

  • getとrunQueryの差

    • getはバックエンドに直接問い合わせる
    • runQueryはindexをつかって問い合わせる

  • ds[kind][key]でエンティティが一意に確定する。これを得るためには.key(kind, key)でkey型を得て、.get(key)でEntityを得ることができる（idとプロパティのペア）。

    • Entity typeは、ここに説明があるのだけど、.id, .kind, ["propertyname"]でアクセスできるらしい。

Dialogflow

Dialogflow 言語解析エンジン 音声入力で問題となりやすい自然言語の解析を簡単にやってくれる機能。 これを挟むことで言語解析のややこしいところを大幅に削減できる。

GCS (Cloud Storage)

  • GAE, GCE, BQ, CDのBackend Storageとして使える

  • 特徴

    • オブジェクトストレージ
    • エッジキャッシュ
    • データはStrong Consistency, ACLはEventual Consistency

  • ストレージタイプ

    • Multi-Regional: 複数のリージョンにデータを分散
    • Regional: 単一のリージョンの複数のゾーンにデータを分散
    • Necling: 月一回程度のアクセス
    • Cold Line: 年一回程度のアクセス

  • GCP全体->バケット->オブジェクトの順に階層がある

    • オブジェクトはたとえば画像イメージみたいなもの
    • オブジェクトに対してそれを取得するためのHTTPリクエストを投げることができる
    • オブジェクト自体にはディレクトリのような階層構造はないが、名前にスラッシュを入れることで擬似的にそう扱うことはできる

  • かなりいっぱいオプションのバリエーションを用意して、どれが一番良かったでしょう？みたいなGCSのコマンドがあると良さそう。

  • Object split / compose

    • splitコマンドで分解したファイルをあとでcomposeするのは非常によくやられる方法。GCS上ではgcloud compose part-* resultの形で行うことができるらしい。

  • GCSのtransferというものでAmazon S3からデータを取ってくるみたいなことができる。

gsutil

  • catした結果をパイプで繋いでgsutilに渡す。→リストに書いてあるファイルが全てコピーされる
cat files.txt | gsutil -m cp -I gs://my_bucket

権限