![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
免責事項 †
概要 †
目次 †
強み †
疑問 †
基本構成 †
用語 †
一般的なクラウドサービスの知識 †
サービス †L7リバースプロキシ †dispatch.yaml や dispatch.xml はGoogle App Engine(以下GAE)のFrontendでルールベースでL7 HTTP Reverse Proxyしてくれるものです。 これはMicroservicesをやる上では大変便利なものになっています。 L7リバースプロキシなので、全てのサービスが立ち上がっている状態じゃないとデプロイできない（してもいいけどない） Google App Engine Standard †
GAE Standard, GAE Flex †
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 †
Firestoreには、ネイティブモードとDatastoreモードの二種類があり、どちらか一方しか選ぶことしかできません。 ネイティブモードは、簡単に言うとFirebase Realtime Databaseの機能が使えるモードです。 Datastoreモードは、その名前のとおり、FirestoreのストレージレイヤでDatastoreのシステム動作するモードです。（正確にはDatastoreモードがDatastoreの後継です。） Firestoreとして一括りにされる傾向が強い印象ですが、DatastoreモードではFirestoreの主な機能であるリアルタイム機能が使えなかったりするなど、Firestoreと言ってもまるで別のサービスと考えた方が良いと思います。 Firestore for realtimeという全然違うものがあるらしい。 Memstore †
Memcacheというものは、データがいつか消えてしまうかもしれないhash関数。Storageにアクセスするのに比べたら圧倒的に早いのが特徴。これって各インスタンスごとに定義されると思っていい？それとも全インスタンスで共有？ 制限時間を設定することもできる（当然保証はできないけど） memcache は他の一時的な値にも便利です。ただし、memcache のみに値を保存し、他の永続ストレージを使用しないかどうかを検討する場合、値が突然使用できなくなったときに、アプリケーションが適切に動作するようにしてください。 新しくできたインスタンスのためにmemcacheを用意しようみたいな話があるので、おそらくはmemcacheはインスタンスワイズの話なんだろうなあと思う Dialogflow †言語解析エンジン 音声入力で問題となりやすい自然言語の解析を簡単にやってくれる機能。 これを挟むことで言語解析のややこしいところを大幅に削減できる。 Google Compute Engine (GCE) †
GCF †
Datastore †
Dialogflow †Dialogflow 言語解析エンジン 音声入力で問題となりやすい自然言語の解析を簡単にやってくれる機能。 これを挟むことで言語解析のややこしいところを大幅に削減できる。 Cloud Storage (GCS) †
Google Cloud Repository (GCR) †
Google Cloud SQL †
gcloud sql instances create myinstance2-replica2 --master-instance-name=myinstance2 を走らせた後にctrl-Cを押してもインスタンス作成はキャンセルされずに作られる。 SQLはstart timeというコンフィグが会って、 start of a 4-hour backup windowでバックアップが取られる。そのためコネクションが4時間に一回増える。 リードレプリカは全然削除を気軽にしても大丈夫。なぜならリードレプリカだから。最悪管理コマンドで消しても作り直せばよいし、再起動くらいなら全然やってよい。 MySQLの MySQL 5.6以降ではデフォルトでONに設定されるようになったパフォーマンススキーマですが、MySQL 5.5時代をご存知の方は明示的にOFFにしているかも知れません（MySQL 5.5のパフォーマンススキーマはパフォーマンスへのオーバーヘッドが非常に大きかった上に、大量にメモリーを利用した）。最近のパフォーマンススキーマはON/OFFに再起動が必要な点こそ変わりませんが、パフォーマンスオーバーヘッド、メモリー使用量ともに大幅に改善されています。また、取得できる情報も「ステートメント（ダイジェスト）単位での各種待ち状態の統計」、「各ステージでの経過時間」、「トランザクション単位での統計」などが追加され、さらに「スキーマ単位、テーブル単位で記録するか否か」、「ユーザー単位、ホスト単位で記録するか否か」を設定できるようになっています。 A cascading failure is a failure that grows over time as a result of positive feedback. It can occur when a portion of an overall system fails, increasing the probability that other portions of the system fail. For example, a single replica for a service can fail due to overload, increasing load on remaining replicas and thereby increasing their probability of failing, causing a domino effect until all the replicas for a service are down. https://miyabi-lab.space/blog/31 ただのバックアップではなくマスターへの変更を即座に反映することができるバックアップなのです。 さらに、災害などでマスターが属しているデータセンターに異常が発生し、マスターの機能が停止してしまった場合にもこのスレーブは働いてくれます。 なぜなら、スレーブが代わりにマスターへ昇格することでデータベースを安定稼働させ続けることができるからです。（これをフェイルオーバーと呼びます。） リードレプリカとは、マスターからレプリケーションされた読み込み専用のデータベースです。 リードレプリカを使用する設計だとデータ読み込み（SELECTクエリ）を行う場合はリードレプリカが処理します。 そして、その他のデータの削除（DELETEクエリ）、更新（UPDATEクエリ）、追加（INSERTクエリ）に対してはマスターが処理を行います。 データベースでは書き込みよりも読み込み比率の方が高いため、データベースへのアクセス頻度が高くDBサーバのリソースが逼迫している場合などの際に、読み込みを複数の「リードレプリカ（読み込み用のレプリカ）」に分散して処理をさせることで、全体のパフォーマンス向上させることを目的としています Cloud SQLでフェイルオーバーが発生するとフェイルオーバーレプリカがマスターに昇格します。 この時、フェイルオーバーレプリカのIPアドレスはマスターのIPアドレスに変更されます。 マスター側の復旧は約100秒ほどのようです。 フェイルオーバーレプリカ側の復旧は約390秒ほどのようです。 マスターはデータが増えても、復旧までの時間は変わらないようです。 フェイルオーバーレプリカはデータが増えると、復旧までの時間が増えていくようです。 第 2 世代インスタンスは、フェイルオーバーを持つ場合は高可用性構成になります。フェイルオーバー レプリカは、マスターと呼ばれる元のインスタンスと異なるゾーンにあることが必要です。ユーザー テーブルを含むマスターのすべてのデータ変更は、semisynchronous レプリケーションを使用してフェイルオーバー レプリカに複製されます。 SQLはICMPを返さないのでtelnetが必要 この３つを全部見る https://cloud.google.com/vpc/docs/private-access-options#private_services_access_and_on-premises_connectivity https://cloud.google.com/vpc/docs/configure-private-services-access https://cloud.google.com/vpc/docs/using-vpc-peering#update-peer-connection プライベートアクセスとか言うのがある。 RFC1918は、要するにプライベートIPアドレスってこと。 限定公開のGoogleアクセス＝内部IPのみを持って外部IPを持たないもの→デフォルトのインターネットゲートウェイ経由でパブリックIPに接続。←要するに、外部IPを持たないのにGoogleのAPIにはアクセスできるよ オンプレホスト限定公開Googleアクセス＝内部IPが必要、外部IPは任意。←VPNトンネルを介して、外部IPを持っていなくてもGoogle APIに接続できるよ プライベートサービスアクセス＝内部IPを持ってやる。外部IPを持つこともできる（SQLとかのやつ）。Google, third partyの管理するinstance向け 限定公開のGoogleアクセス→内部IPしかないのにGoogleのAPIにつながる！不思議！（サブネットレベルでオンオフ） Dataflow †裏でオープンソースのものを使っているので難しい HiveやPigでTezを使うのはすごく簡単です。 Hiveの場合、 set hive.execution.engine=tez; など、hive.execution.engine変数にtezという値を入れてやります。 Pigの場合も起動時に $ pig -x tez set exectype=tez; HiveはSQLっぽくHadoopのmap reduceパイプラインを作るためのツール。もともとはFacebookが作った。 他の言語としては以下がある Cloudera Impala -- allows you to query Hadoop data using SQL, but does not utilize Mapreduce under the hood so can run faster. i.e. more similar to Dremel in architecture. See https://vision.cloudera.com/impala-v-hive/. IBM BigSQL HAWQ Hadapt Apache Pig -- new language for specifying a Mapreduce against Hadoop data. Simpler than writing Java code. Originally created by Yahoo. HBaseはこのHDFS上に構築するデータベースです。HBaseとHadoop（HDFS）の関係を図4に示します。なお、HBaseの構築にYARNとMapReduce?は必須ではありませんが、MapReduce?を使用するとHBaseのデータ格納/参照を高速に行えるため、YARNとMapReduce?も同時にインストールすることを推奨します。 NoSQL RDDとは、以前にも書きましたが「不変(イミュータブル)で並列実行可能な(分割された)コレクション」 RDD(A Resilient Distributed Dataset (RDD),)に保持したデータを操作するメソッドは大きく分けて2つに分類されます。「Transformations」と「Actions」です。「Transformations」はRDDを操作し、結果を新しいRDDとして返します。「Transformations」の代表的なメソッドは、mapやfilterです。「Actions」はRDDのデータを操作し、結果をRDD以外の形式で返すか保存を行います。大雑把に言えば、RDDを返すのが「Transformations」、そうではないものが「Actions」であると言えると思います。 得意 Hadoopで加工したのちのドリルダウン分析 TB級までのデータを扱うシステム サンプリングが有効でないロングテールのデータ分析 数秒~数分程度のHadoopよりも短いレスポンスが必要な処理 不得意DataflowではShufflingのときにhotspottingという問題が起きる可能性がある。これはa-m, n-zの辞書順で分けたときに、どっちかがあめっちゃ多くなるコーナーケースがある可能性があるから クラスタ全体のメモリに乗りきらない巨大なデータ処理(TB以上) 大きなデータセットを少しずつ更新する処理 秒以下の時に短いレスポンスが必要な処理 Hadoopの欠点と言われていたのが主に以下の三つ 個々のメモリを活用できる設計でなかった(タスクごとにデータをディスク読み込み&書き込みしなきゃいけないのがボトルネック) 同じ処理を複数行う際に、その都度データアクセスが発生 同じデータでもなんども使うものは使う際に無駄にアクセスがいっぱい発生 この課題を解決するのがRDD(Resilient Distributed Datasets)というSparkの分散共有メモリの仕組みです。 すごくざっくり言うと、Hadoopでは毎回ストレージにアクセスしたりしていたのがインメモリで実行できるのでいいこといっぱいあるよねって感じだと解釈しました。 YARNとHDFSって何 (*1)HDFS:MapReduce?で処理するデータを扱う、分散ストレージとして複数のマシンを一つのストレージとして扱うことができる。 HDFSは管理するファイルのI/Oを高速化するため大きなファイルを一定の大きさ(初期設定では64MB)のブロックに分割して、複数の記憶装置に分散して保存、I/Oを記憶装置の台数だけ並列に実行できるようにしている。 HDFSは並列でよめるファイルシステム。Hadoop Distributed File System Sparkはインメモリにすると早いよねなので、クラスタのメモリがなくなると当然弱い（遅延評価しているとはいえ）。 データをインメモリにロードする部分はSparkContext?と呼ばれるtextFileのようなファイルシステムからダウンロードしてくるような関数が提供されている。一方で、parallelizeという関数があってこれはプリミティブなデータ構造（配列とか）をRDDにするための関数。 RDDはデータそのものではなく、「RDDsを構築するためにデータに対して行った変換」を記録することで効率的な耐障害性を実現している。 もしRDDの中の一部分がロストした場合、RDDはそのデータが他のRDDからどのように変換されて生じたデータかを保持しているため、コストの大きなレプリケーション(*5)なしに迅速に再計算/復旧させることができる。 . 系譜のステージへの分割 DAGSchedulerが、系譜をスケジュールに分割する ステージは系譜中で狭い依存関係が連続して発生する範囲(依存関係の種類は変換の種類できまる) 系譜中で広い依存関係が発生する変換関数を処理する場合はエグゼキュータ間でシャッフルと呼ばれる多数対多数の通信が発生する。 この分割は、パーティションごとに一つのエグゼキュータがまとめて計算できる変換の範囲を決めるため なので、sparkの実装にdataflowを使いたくなるのはすごく気持ちがわかるねという感じ RDDは静的なので静的なデータの変換を行うために、関数型で物体そのものを定義するというのは妥当な感じがする YARN は、以下の図に示す次世代の Hadoop 計算プラットフォームです。イメージクラスタのマスターがYARN masterでworkerがYARN slaveと呼ばれるっぽい。YARN slaveはMapreduce マスタ・スレーブをコンテナとして起動する感じになる。 プログラマブルでやれることがちょっと限られているdataflowみたいな感じかな Cloud Dataproc service – receives job requests from the user and submits the request to the dataproc agent dataproc agent – runs on the VM, receives job requests from the Cloud Dataproc service, and spawns driver driver – runs customer-supplied code, such as Hadoop jar, spark-submit, beeline, and pig applications Dataprocではselectorというのがあって、これはクラスタを冗長化してジョブをランダムにクラスタアサインする Jobが失敗したら全てのジョブがキャンセルされて今後のものもキャンセルされる。 Dataflowのスケールは、今後やるべきタスクの数によってスケールする。これはコストの制御のために行われている。つまるところ、レイテンシを固定化するようにスケールしているということ。行うタスクが小さいときにレイテンシがおそいのはWAI Dataflowはレイテンシを固定するように動くので、少量のデータだと遅い DataflowではShufflingのときにhotspottingという問題が起きる可能性がある。これはa-m, n-zの辞書順で分けたときに、どっちかがあめっちゃ多くなるコーナーケースがある可能性があるから Composer †コンポーザーはデータレイク（色んな所の生データ）にあるデータにドメイン知識を反映してデータウェアハウスにして(Hadoop)にして、特定用途向けに加工整理してデータマート（Tableau、Bigquery）にするという感じ。すぐに使える完成品を取り揃えていることからマート（市場）と呼びます。ウェアハウスは複数のデータを統合・蓄積して、意思決定に活用できるように整理したものです。 DAGフィアルはDAGを定義するだけで実際のデータ処理はworkirにやらせる。通信とかはチア変なのでXComというものを使うことによっていい感じにする AirFlow?のオペレータにはめちゃくちゃいっぱいGCP系のものがある（DataflowとかDataprocとかStorageとかどこからどこにコピーするとか何でもあると言っても過言ではない） 従来の Cloud Dataflow ジョブ Apache Beam パイプラインの開発とジョブの実行は、すべて開発環境内で行われます。 開発者が開発環境を作成し、パイプラインを開発します。環境には、Apache Beam SDK やその他の依存関係が含まれます。 ユーザーが開発環境からパイプラインを実行します。Apache Beam SDK が Cloud Storage 内のファイルをステージングし、ジョブ リクエスト ファイルを作成し、そのファイルを Cloud Dataflow サービスに送信します。 テンプレート化された Cloud Dataflow ジョブ Cloud Dataflow テンプレートを使用する場合、ステージングと実行は別のステップです。このように分離されているため、ジョブを実行できるユーザーとジョブの実行元となる場所を柔軟に決定できます。 テンプレート化された Cloud Dataflow ジョブの典型的なワークフロー: 開発者が開発環境を作成し、パイプラインを開発します。環境には、Apache Beam SDK やその他の依存関係が含まれます。 開発者がパイプラインを実行し、テンプレートを作成します。Apache Beam SDK が Cloud Storage 内のファイルをステージングし、テンプレート ファイル（ジョブ リクエストと類似したもの）を作成し、Cloud Storage 内にテンプレート ファイルを保存します。 開発者以外のユーザーは、GCP Console、gcloud コマンドライン ツール、REST API でジョブを簡単に実行し、テンプレート ファイルの実行リクエストを Cloud Dataflow サービスに送信できます。 Spark runnerは分散用 Direct runnerはサーバ一大で開発・デバッグ・テスト用に作られたBeasmに付属した欄な Cloud Launcher †https://qiita.com/NagaokaKenichi/items/41ee9d8ba40555eaf2b7 Cloud Launcherというサービスがあって、これをつかうとpredefinedのjenkinsなどをGCE上に立ち上げることができる。 Cloud Build †GCBはCI/CDとして見るとCircleCIと比べてまだまだ扱いづらいところがあります。一方で、従量課金制のフルマネージドなビルドサービスというCircleCIとは違った使い方もできるところが特徴と言えます。 BigTable? †HBase BigTable?のapache版。こっちからBigTable?に移行したい、あるいはベンダーロックを嫌うためにHBaseっぽいクライアントライブラリが提供されている（ちょっとの差はあるけど） com.google.cloud.bigtable.hbase.BigtableConfiguration?が全てのhaddp系と全く同じインターフェースの関数群を提供しており、それから先はほぼhadoop.hbaseと同じように操作できるよ！という感じ。 このナレッジベースがかなりよいので一読の価値がある 数については知らないのでページの機能をいい感じに実装するのは厳しそう Filter filter = new PageFilter?(pageSize); BTでもない BigTable? Cloud Bigtable は行をアトミックに読み取ります。このため、一回の更新が1行で収まるようにする努力が大切で、1 行に格納するデータ量の合計を制限することは非常に重要です。1 つのセルに格納するデータを 10 MB 以下にし、1 行のデータを 100 MB 以下にするのがベスト プラクティスです。 BigTable?は二次主キーを作ることができないが、列ファミリーをいくつか作ってその中では辞書順ソートされるようにできる。 Java+BigTable? githubのcloud-bigtable-examples/java/hello-worldのgithub上のREADMEに従ったら一瞬でできた。mavenを一から書くにはたいへんだな… put.addColumnみたいなのをやると、Bigtableの各列はector<map<string, multiset<string>>>みたいなものなので、その列ファミリーが指定するsetにappendされる mvn package mvn exec:java -Dbigtable.projectID=wakataberyo-sandbox2 -Dbigtable.instanceID=bigtable-test BigTable?の列ファミリーって何 BigQuery? †clusterというのがある、同じ日のものは同じ場所に置くので料金が安くなったり速度が早くなると期待している。 検索バイト数が増えたり減ったりしている。
# 半角数値 x を全角文字列に変換する関数 CREATE TEMP FUNCTION TO_MULTI_BYTE(x INT64) AS ( CODE_POINTS_TO_STRING(array(select c + 65248 from UNNEST(TO_CODE_POINTS(CAST(x as STRING))) as c)) ); # 全角文字列 x を半角数値に変換する関数 CREATE TEMP FUNCTION TO_SINGLE_BYTE(x STRING) AS ( CAST(CODE_POINTS_TO_STRING(array(select c - 65248 from UNNEST(TO_CODE_POINTS(x)) as c)) as INT64) ); BQの配列アクセスarr[1]は arr[OFFSET(1)] BQの一時テーブル作成において、以下のようにすると楽。 FROM UNNEST([1, 2, 3, 4, 5]) AS numbers; To convert an ARRAY into a set of rows, also known as "flattening," use the UNNEST operator. UNNEST takes an ARRAY and returns a table bigqueryにはパーティションとクラスターという二つの方法がある パーティションは基本的には時間分割。自動で一日ごとに分割する方法と、維持分で分割方法を考える方法とがある クラスタ化とは、あるソート可能な要素を最大4つまで指定できる。クラスタ化ではディスクのランダムIOを減らすという目的になっているので、insertなどに弱い 性別というカラムはmale、femaleの2種類程度であるのでカーディナリティが低いです。 一方、マイナンバーというカラムは被りがないので非常にカーディナリティが高いです。 インデックスはカーディナリティが高いものを設定するとより効果的です。 こんなの当然で、uniqueのものが入っていると矩形クエリにいっぱい入り込む可能性があるので。。 インデックスが設定されているとレコードが挿入された時に平衡二分木なりなんなりのinsertが発生するので、insertは遅くなる。インデックスが二つといったときには、1次元のindexが二個なのか2次元のindexが1個なのかについては考えたほうがいい。多次元拡張するとしても例えばSegment TreeであってもO(log^2 n)になるので、インデックスを多次元にしてWHERE句で多次元indexを実現しようとすると当然insertに時間がかかる。一方で、1次元のindexが二つだという過程にたったとしても、insertを行うのにindexの更新すべき木の数が2倍になっているので時間がかかる。 なので、 索引を増やすとinsertの時間がかかってしまったりするので、readとwriteのパフォーマンスのトレードオフでどんな索引を作成スべきかという話を考えれば良い。 bigqueryは実際に処理されるデータとか金額は違うし、それがいつ決まるかもダイナミックに決まるので、よくわからない byte billedというのは正確 BQは、project 1:many dataset 1:many tableの構造になっている。 datasetではcreate tableというのがWeb UIからできてファイルを追加できる table のデータ構造<string, string, integer>などは、Schemaと呼ばれる。 Pub/Sub †
Dataproc †
GCE †
Kubernetes †GKE クラスタ ノード＝マシン プール＝すべてが同じように構成されたノード インスタンスのサブセット（はじめに構成したときのノードはデフォルトノードプール） ポッド＝プロセス＝Docker コンテナなどのコンテナが 1 つ以上リソースを共有。ポッド内のコンテナは、ポッド内で localhost を使用して互いに通信します。デフォルトでは、ポッドはクラスタのデフォルト ノードプール内のノードで実行されます。作成されたポッドは、自身のプロセスが完了するか、自身が削除されるか、リソース不足のために自身がノードから強制排除 (evict)されるか、ノードに障害が発生するまで、ノードに存在し続けます。 GKEはCluster生成時にGCEのインスタンスグループを作るので、そのグループに対してオートスケールの設定をすることができる。前述のPodの水平オートスケールと合わせると次のようなシナリオが考えられる。 アクセスが増える Podに割り当てられたCPUリソース使用量が閾を超える Podがスケールして増える Podが増えたことでNodeのCPUリソース使用量が閾を超える Nodeがスケールして増える アクセスが減る PodのCPUリソース使用量が閾以下になる Podが減る NodeのCPUリソース使用量が閾以下になった状態でクールダウン期間を経る Nodeが減る 永久機関感ある。自分は実際にこの構成で運用し始めている。今後問題が生じたらまたエントリにしようと思う。 https://knowledge.sakura.ad.jp/16082/ GKEを理解したい Docker: コンテナとイメージというのがあって、イメージからコンテナを作る感じ。コンテナをイメージにするコマンドもあるし、どのようにそのコンテナを作ったかを記録しておいてそれをスクリプト的に走らせて再現性高くコンテナを作ることもできる（Dockerfile）。DockerではDockerネットワークという仮想的なコンテナ間通信を行うことができる。 複数ホストでコンテナを起動して、コンテナ間通信するには、今回説明したことの他にも必要な設定があります。そこで活躍するのが、KubernetesやDocker Swarmなどのコンテナオーケストレーションツールになります（今はKubernetesがデファクトスタンダードとなっています）。 k8sはこれがわかりやすかった https://news.mynavi.jp/itsearch/article/devsoft/4097 1つ目は高い抽象度です。Dockerコンテナは通常一台のサーバ内に閉じて構築されます。複数台のサーバにまたがるコンテナ環境を構築するためには、ネットワークにおけるNAT設定など、さまざまな設定が必要になります。 こういった問題にアプローチするのがKubernetesです。Kubernetesを使うとコンテナのクラスタ化が容易になります。クラスタはサーバ単位でコンテナを管理するPodと、サーバをまたがるPodを管理するReplicaSet?の組み合わせで構築されます。 2つ目は高い信頼性・回復性です。セルフヒーリングと呼ばれ、障害により設定された台数を下回った場合には、自動的にコンテナが再起動されます。これにより、ゼロダウンタイムを実現します。 3つ目は中立性です。Kubernetesを実現するサービスはGoogle Cloud PlatformやOpenStack?などさまざまに存在します。CNCF(Cloud Native Computing Foundation)により標準化されており、Kubernetesが各クラウドを抽象化する層を担うことで、ベンダーロックインを防ぎます。 ハイパバイザ 従来のホストOS型は、HW->OS->仮想化->ゲストOS ハイパバイ座敷は、HW->ハイパバイザ仮想化->ゲストOSとなっている。 ハイパバイザの一つの例としては、Linux自体をハイパバイザにしたQEMUというのが有名（発表して二週間でLinuxにマージされたので）。これはLinuxだからホスト型じゃない？と思うかも知れないけど、ハイパバイザの上で通常のプロセスを走らせることなく、ゲストOSをのせるという点で少し異なる 技術的な差異は主に３つある。(1) 仮想化支援機能を有するCPUを前提としていること。通常ソフトだけで仮想化してx86の上でarmなどの違うアーキテクチャを動かすとその計算のエミュレートが大変だったのだが、CPUがその機能を提供するようなCPUが販売されるようになったので、パフォーマンスがよくなった（CPUを限定してゲストOS側を最適化・改造が必要な準仮想化に比べると遅いけど）。(2) KVMは独自にハイパバイザを開発するのではなく、Linuixのデバドラを流用できるのでハードウェア対応が容易 (3) KVMでのゲストOSはプロセスとして管理される（！）ので、killとかCtrl-CによるゲストOSの削除が可能になる KVMは完全仮想化に際して仮想化支援機能を有するCPUを要求する（HWに対する制約がある）。使用している機器にCPUの仮想化支援機能があるかどうか分からない場合は、/proc/cpuinfoを見てみるとよいでしょう。Intel VTの場合はvmxが、AMD-Vの場合はsvmがあるか否かが1つの判断基準となります。 apt-get install kvm bridge-utilsみたいなやつをやって、kvm-img create -fとかいうかなりお手軽間を醸し出していることをすることによってkvmがインストールできたりOSがインストールできたりしてすごい KVMはただでさえ仮想化していて物理的なサーバの位置がよくわからないのに、物理サーバの位置が多くなってくると本当にわけわからなくなってしまう。なので、こういうときに使うためのKVM運用ツールoVirtというものがある。 Cloud tasks †Google Cloud Tasks … GAE 内のサービスである「Task Queue」を、GAE 以外でも利用できるようにしたもの。 Google Cloud Pub/Sub リリース当初は、Task Queue をなくして Pub/Sub に一本化する予定だったそうだが、 Pub/Sub では吸収しきれない要望がたくさんあったため、存続決定とのこと。 HTTP PUTを定期的に投げるだけのサービス（タスク：このHTTPリクエストをここに投げといてという依頼） 「POSTを積む、POSTを投げる」 投げる先はオンプレでもGCEでもApp Engineでもありえる。Google内部だといろいろ楽なので楽（例としてHTTPリクエストを…と言ったときにターゲットがApp Engineだったらprojectからの相対パスで指定できるので）。 ターゲットはPOSTに対して200台を返す義務がある。返さないとリトライとかされる。 Cloud Tasksからのリクエストには、どのキューからPOSTされたのかなどのヘッダーが書かれている。 こういうタスク系は非常に重くて特殊なものを使いがちだと思うので、GAEではなくGCEがそれを受けるというのが現実的になりそう 数百万または数十億のような多数のタスクを追加する必要がある場合、二重注入パターンが便利です。1 つのジョブからタスクを作成する代わりに、インジェクタ キューを使用します。 このTask Queueには、キューに追加した処理がGAEにより自動実行されない Pull Queue という種類があり、これを使うとGAEではない外部のプラットフォームからキューに入っている処理を引き出す事ができます。 StandardはTask queue, FlexはCloud tasks/PubSub?を使うべき（本当？StandardもCloud tasksのほうが良くない？） Spanner †Indexを動的に追加することがindex backfills これをやっている間は追加のリソースが使われる。 indexを動的に追加すると、indexに整合しているかを確認するためのverification, refillの処理がバックグラウンドで走る。この間はCPU usageが高くなる Google Spanner is really an incredible solution for databases in the cloud and there is no competidor reaching this excellence. I use AWS but GCP on this case is unique. Spannerにはクエリのパフォーマンスを測るためのビルトインテーブルが提供されている https://cloud.google.com/spanner/docs/query-stats-tables#listing_the_basic_statistics_for_each_query_in_a_given_time_period Networking †Route †
VPC †VPC GCPにマルチリージョンでプライベートネットワークを構成 オンプレも可能（トンネル） 公共のネットワークを使わない GCEインスタンスとかだと、特に全部のサーバに正しくACL設定できるかとかかなり不安なので、VPCでセキュリティは大丈夫だよという感じにしておいたほうが安心だねとなる これ読んで理解して。かなり良い記事 Cloud NAT †Network tags †ネットワークタグ 要するに、CIRDで指定するのは連続を前提としていて辛いから、インスタンスに直接タグをつけて、グループAからグループBのポート80には通信ができますよーみたいな感じにするのが良いという話だと思う。 上りファイアウォール ルールを作成するときは、ソースを指定する必要があります。ソースを定義するには、内部 IP アドレスまたは外部 IP アドレスの範囲を使用するか、特定のインスタンスを指定します。インスタンスを指定する場合は、ソースタグまたはソース サービス アカウントを使用します。 VPN †
ゲートウェイ †デフォルトゲートウェイはパケットがパブリックに流れる。 このネットワークを使って、Compute Engine 仮想マシン（VM）インスタンス、Kubernetes Engine クラスタ、App Engine フレキシブル環境インスタンス、プロジェクト内のその他のリソースを接続できます。 ということは、VPCはApp Engine Standardをつないでいないということ？ VPC ネットワークの特性は次のとおりです。 関連ルート、ファイアウォール ルールを含む VPC ネットワークはグローバルなリソースです。特定のリージョンやゾーンには関連付けられていません。 サブネットはリージョン リソースです。サブネットごとに IP アドレスの範囲が定義されます。ネットワークとサブネットの詳細については、ネットワークとサブネットをご覧ください。 プロジェクトにまたがったVPCは無理で、それをやるためにはVPC peeringを行う必要がある Debugging †
Stackdriver Debugger †
Monitoring †
Stackdriver Logging †loggingで dremdataflot.googleapis.com/worker-startupやkubeletやshuffler0starrrrtupなどの指定をlog typeに指定することができる KVMとかシステム的なやつの場合にはlogsの指定をそういう感じにすると良い。 back -> front -> cx -> stackdriver でcxとstackdriverは並列！backが成功していてcx, stackdriverが落ちている場合、frontがbackのものを渡せていないとかそういうやつだと思う。 言語 †Java †JavaでLocalをチェックするための方法として、以下のものがある。要するに、環境変数的な感じでSystemからappengine.appid private static final String APP_ID = System.getProperty("appengine.appId");
private static final String APP_VERSION = System.getProperty("appengine.version");
private static final boolean LOCAL_TEST = null == APP_ID || null == APP_VERSION;
app.yamlにそうとうするものは、javaのばあいsrc/main/webapp/WEB-INF/appengine-web.xmlになっているっぽい。ここの部分でランタイムをxmlとして入力し、 Javaのweb-??.xmlみたいなやつ（app.yamlのJava ver）では、serviceが何故かmoduleという表現になっている あと、appIdって見たらプロジェクトIDのことだと思う必要がある インスタンス設定 †
デプロイ †
初期設定 †
curl https://sdk.cloud.google.com | bash exec -l $SHELL gcloud init # ちゃんとログインページに飛ばしてくれないので、リンクを手でコピペする ssh †gcloud compute ssh instance-1 --zone us-central1-c GCPでコマンドが無い時に自動終了するスクリプト †https://twitter.com/imos/status/923551881166602240 月2ドルとかで超安くサーバが使えるように鳴るらしい Googleクラウド お金がクレジットある状態だと不明瞭なのまじね。試しに使って見て、これくらいかーとなるもんじゃないの Logging †Stackdriver Logging †
Stackdriver Trace †https://cloudplatform-jp.googleblog.com/2018/05/viewing-trace-spans-and-request-logs-in-multi-project-deployments.html また、トレースの一部となっている全プロジェクトからのリクエストに関するログ エントリの表示も可能です。これには関連するプロジェクト側に “logging.logEntries.list” の権限が必要で、ログを Stackdriver Logging に書き込む際は、“projects/[PROJECT-ID]/traces/[TRACE-ID]” というフォーマットで LogEntry? オブジェクトの trace フィールドを設定する必要があります。LogEntry? の span_id フィールドを、16 文字の 16 進数でエンコードされたスパン ID として設定し、ログを特定のトレース スパンと関連づけることも可能です。詳細はこちらのドキュメントを参照してください。 Fluentd を介して Google Kubernetes Engine もしくは Stackdriver Logging エージェントを利用する場合は、“logging.googleapis.com/trace” や “logging.googleapis.com/span_id” というキーを使って構造化ログを書き込むことで、LogEntry? オブジェクトの trace や span_id フィールドを設定できます。詳細はこちらのドキュメントを参照してください。 トレース スパンに関連づけられたログ エントリを表示するには、“Show logs” をクリックしてください。 ということは、これはStackdriver Traceと同等の機能なのか。 Cloud Activity †パーミッションチェンジみたいなやつは、Cloud Activityで得ることができる。Cloud ActivityはもともとStackdriverのAdmin操作のみを取り出したもので、 Cloud Activity (Home > My Activity) of your "snap-crackle-proxy" project and then filter for resources "GCS bucket". gcloud †gcloud app logs read gcloud app logs tail Appengineのstackdriver logging的なものが得られる。各サービス、HTTPリクエスト、loggingが割と読みやすい形式で撮ってくれる。 結構遅延がある (30分) 課金 †
「一日何回くらい演算をしますか？」 「2×10^15回くらいですね」 「演算年数は？」 「30年くらいです」 「あそこにベンツが停まってますね」 「はい」 「もし演算やめたらあのベンツが買えるんですよ」
GAE Standardは1時間あたりのインスタンス数が1だと、だいたい30USD/monthくらいになる GAE Flexは1時間あたりのインスタンス数が1で1ヶ月動かすと、だいたい90USD/monthくらいになる。結構高いな。 Storageは結構やすい。40GB/Monthで1USDくらい。1TB/monthで26USD/month (multiregional). single reagionalとしても20USD/monthにしかならないので、multi-regionalは結構お得。Coldlineとかだと、1TB/monthが5USDだが、データ操作の方が2倍位高い プリエンプトは一応終了までに30秒の猶予がある Compute Engine は、プリエンプションの通知を ACPI G2 ソフトオフ信号の形式でインスタンスに送信します。シャットダウン スクリプトを使用して、プリエンプト通知を処理し、インスタンスが停止する前にクリーンアップ操作を完了できます。 SQLのmachine typeははじめstandardなのでちょっと高いよ アクセスコントロール †
言語別比較 †
|
