Google Cloud Platform Japan 公式ブログ

API デザイン : URL には名前と識別子のどちらを使うべきか

2017年11月10日金曜日

https://ebank.com/accounts/a49a9762-3790-4b4f-adbf-4577a35b1df7https://library.com/shelves/american-literature/books/moby-dickGoogle Cloud Platform API Design Guide 識別子の長所論文階層構造の名前自然の分類法両方の長所を取り入れるにはGoogle Cloud Platform 識別子はルックアップ用、名前は検索用https://ebank.com/accounts/a49a9762-3790-4b4f-adbf-4577a35b1df7https://library.com/shelves/american-literature/books/moby-dickhttps://library.com/search?kind=book&name=moby-dick&shelf=(name=american-literature) 名前と識別子の併用https://ebank.com/accountshttps://ebank.com/accounts/a49a9762-3790-4b4f-adbf-4577a35b1df7https://library.com/locations{"kind": "Shelf", "name": "American-Literature", }https://library.com/shelf/20211fcf-0116-4217-9816-be11a4954344https://library.com/inventory{"kind": "Book", "name": "Moby-Dick", "location": "/shelf/20211fcf-0116-4217-9816-be11a4954344" }https://library.com/book/745ba01d-51a1-4615-9571-ee14d15bb4afhttps://library.com/shelf/american-literatature/book/moby-dickhttps://library.com/search?kind=book&name=moby-dick&shelf=(name=american-literature)https://library.com/book/745ba01d-51a1-4615-9571-ee14d15bb4af 2 種類の URL を持つ方法の欠点パーマリンクと検索 URL の “いいとこ取り”Web API Design : The Missing Link投稿記事* この投稿は米国時間 10 月 17 日、software developer および API designer である Martin Nally によって投稿されたもの（投稿はこちら）の抄訳です。- By Martin Nally, software developer and API designer

Cloud Launcher で新たに 21 のオープンソースソリューションが利用可能に

2017年11月9日木曜日

Google Cloud LauncherClick to Deploy

こちらGoogle Cloud Platform無料トライアル* この投稿は米国時間 10 月 18 日、Product Manager である Quan To によって投稿されたもの（投稿はこちら）の抄訳です。- By Quan To, Product Manager

優れた SLO を策定するには : CRE が現場で学んだこと

2017年11月8日水曜日

CRE シリーズSLO、SLI、SLA について考えるSRE 本 SLO の意義SLO はサービスレベル契約（SLA）ではない

SLO は、チームがやるべきことについて意味のある疑念を解決する便利なツールとなります。「この課題には絶対取り組まなくては」ということと、「この課題には取り組まなくていいかもしれない」ということの間に線引きすることこそが目標なのです。したがって、SLO のターゲットを必要以上に高く設定しないようにしましょう。現在たまたまその目標値を満たしているとしても、いったん設定してしまうと今後何か変更する際に柔軟性が損なわれるおそれがあります。たとえば、信頼性を犠牲にしても開発速度を上げるべきかということを考える際に、柔軟性が制限されてしまうのです。

SLO にクエリをグループ分けするときには、特定の製品要素や内部実装の詳細ではなく、ユーザーエクスペリエンスによって分けましょう。たとえば、ユーザーの行動に対する直接的なレスポンスは、バックグラウンドや付随的なレスポンス（サムネイルなど）とは別の SLO にグループ分けすべきです。同様に、（製品を閲覧するというような）「読み込み」の操作は、（精算するという操作のように）頻度は低いものの、より重要な「書き込み」の操作とは別グループに入れるべきです。それぞれの SLO においては、可用性やレイテンシの目標値が異なります。

SLO の範囲と、それがどこまでをカバーするのか（どのクエリ、どのデータオブジェクトまでをカバーするのか）、さらにはどういった条件で SLO が提供されるのかを明確にしておきましょう。無効なユーザーリクエストをエラーとして数えるのか数えないのか、また、あるクライアントから多数のリクエストを送られるといったスパムに見舞われたらどうするか、ということについても検討してください。

最後に、上記内容とは若干綱引きの状態になってしまいますが、SLO は簡潔かつ明確なものにしておきましょう。SLO では、本当に気になる部分を曖昧にするのではなく、重要でない操作までカバーしないようにするほうがよいのです。規模の小さい SLO で経験を積んでください。まずはリリースして繰り返すのです。

SLO の例可用性可用性 :可用性 :可用性 :レイテンシレイテンシ : レイテンシ : パーセンテージの理由 100 % の場合は話が別リスクを容認 SLO のレポートSLO 四半期サマリーの例

SLO

目標値

第 2 四半期

第 3 四半期

ウェブの可用性

99.95 %

99.92 %

99.96 %

モバイルの可用性

99.9 %

99.91 %

99.97 %

レイテンシ 250 ミリ秒以下

50 %

74 %

70 %

レイテンシ 3000 ミリ秒以下

99 %

99.4 %

98.9 %

まとめSRE 本* この投稿は米国時間 10 月 23 日、Customer Reliability Engineer である Robert van Gent と Stephen Thorne、および Site Reliability Engineer である Cody Smith によって投稿されたもの（投稿はこちら）の抄訳です。- By Robert van Gent and Stephen Thorne, Customer Reliability Engineers and Cody Smith, Site Reliability Engineer

機密データ保護に有用な DLP API の新機能

2017年11月7日火曜日

今年 3 月にベータリリースData Loss Prevention（DLP）APIGoogle Cloud StorageCloud DatastoreBigQuery 「弊社のセキュリティソリューションでは、複数のクラウドデータストアやメールソースに格納された文書やイメージを、Google Cloud の DLP API によってスキャンし分類しています。これにより、データ管理やリスク緩和に効果的な分類、リダクションなどのセキュリティ機能をお客様に提供できるようになりました。Google のインテリジェントな DLP のおかげで、私たちは高品質なサービスをお客様に提供して差別化を図り、ビジネスの拡大に成功したのです。」
— Sateesh Narahari 氏、ManagedMethods の製品担当 VP DLP API の新しい非特定化ツール

DLP API を使えば、構造化と非構造化の両方のデータに含まれる機密要素を分類、マスキングできる

リダクションとサプレッション

DLP API は、名前、社会保障番号、電話番号、メールアドレスを識別してリダクションできる

部分マスキング

トークン化（セキュアハッシング）

FPE（Format-Preserving Encryption : フォーマット保持暗号化）: 同じ長さと文字セットでトークン化

セキュアなキーベースのハッシュ : データ暗号化キーを使って生成された 32 バイトの 16 進文字列トークン

ダイナミックデータマスキング

DLP API を使えば、機密データをリアルタイムで非表示にできる

バケッティング、k- 匿名性、l- 多様性ドキュメントハウツーガイド使ってみようこちらのクイックスタートガイド* この投稿は米国時間 10 月 19 日、Product Manager である Scott Ellis によって投稿されたもの（投稿はこちら）の抄訳です。- By Scott Ellis, Product Manager

MIT SMR 調査 : セキュリティはクラウドを躊躇する理由ではなく、導入する理由に

2017年11月6日月曜日

注 : MIT SMR Custom Studio が Google Cloud に代わって実施した調査のレポートは、こちらからダウンロードできます。調査レポート

リーダーたちが最近デプロイした主要なワークロードとして挙げたものは何か。近くデプロイしようとしているものは何か。

リーダーたちがクラウドにホストしようとしているデータのタイプはどのようなものか。

データが法的に厳しく規制されている業界では傾向が異なるのか。実際の経験やクラウドの成熟は、クラウドがセキュアかどうかについての見方に影響を与えているのか。脅威は現実に存在していたり、認識されていたりするのか。

セキュリティに関してどのようなレベルの疑念があるのか。職務権限、責任の大きさ、企業の規模によってどのような違いがあるのか。

クラウドのセキュリティに関する信頼性向上の背後には何があるのか。企業は実際にクラウドのセキュリティをどのように評価しているのか。

リーダーたちは組織のセキュリティ要件として何を重視しているのか。

調査レポート* この投稿は米国時間 10 月 20 日、Google Cloud の Trust & Security である Rob Sadowski によって投稿されたもの（投稿はこちら）の抄訳です。- By Rob Sadowski, Trust & Security, Google Cloud