※この投稿は米国時間 2023 年 9 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。 入社したばかりの Java デベロッパーが、簡単な Java サービスを作る仕事を割り当てられたとしましょう。DevOps モデルでは開発チームと運用チームが責任を共有するので、Java コードだけでなく、ビルド パイプラインやモニタリング計測のような運用コードの作成も求められるかもしれません。しかも、クラウド プラットフォームは以前の仕事で覚えたものとは異なります。 あっという間に YAML ファイルの山に溺れ、簡単な Java サービスの構築が難事業になってしまいました。決めなければならないことがたくさんあります。コードの構成はどうしよう？継続的デリバリーにはどのツールを使用したらいいのだろう？ DevOps モデルは開発者に耐えられないほどの学習の手間をもたらすこ

※この投稿は米国時間 2022 年 11 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。 プロジェクトの自動クリーンアップによって時間と金を節約するとともに、セキュリティ リスクを低減する組織のクラウドへの依存度が高まるにつれ、クラウド プロジェクトの数も増えていきます。やがてプロジェクトが無秩序に増え、組織に数十、数百もの不要なプロジェクトが残されかねません。不要なプロジェクトは一括で削除できるとは言え、どのプロジェクトが不要なのかを判断するのは困難になります。プロジェクトを把握するために一つひとつ手作業で調べるとなると、この骨の折れるタスクのために貴重なリソースを無駄にすることになります。さらに悪いことに、不要なプロジェクトがリソースを消費することで、費用も温室効果ガス排出量も増えるだけでなく、セキュリティ リスクも高まります。 Remora の概要R

Hero image credit: Markus Teich At Google we run large production fleets that serve Google products like YouTube and Gmail. To support all our employees, including engineers, we also run a sizable corporate fleet with hundreds of thousands of devices across multiple platforms, models, and locations. To let each Googler work in the environment they are most productive in, we operate many OS-platfor

デジタル トランスフォーメーションを加速 お客様がデジタル トランスフォーメーションに乗り出したばかりでも、あるいはすでに進めている場合でも、Google Cloud は困難な課題の解決を支援します。

※この投稿は米国時間 2021 年 9 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。 編集者注: プロダクトの信頼性は、数多くの規範的規則を守りさえすれば確保できるというものではありません。今回は、Google SRE のメンバー（開発担当シニア テクニカル プログラム マネージャーの Vartika Agarwal、シニア SRE マネージャーの Tracy Ferrell、ディレクター SRE の Mahesh Palekar、SRE 担当シニア テクニカル プログラム マネージャーの Magi Agrama）に、チームの現在の信頼性のマインドセットを評価する方法と、目指すべき姿について話を聞きました。 信頼できるソフトウェア プロダクトがあると、組織に対するユーザーからの信用、開発プロセスの有効性、プロダクト全般の品質を改善できます。サービス停止は

※この投稿は米国時間 2021 年 6 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。 Google の顧客信頼性エンジニアは、Google Cloud のお客様の組織で実践を支援するよう選任された、Google サイト信頼性エンジニア（SRE）です。その仕事の一つに、運用の成熟度を高めるために行う経営陣や SRE チームへのアドバイスがあります。Google はそのディスカッションの多くで、「今やっていることは『SRE の仕事』でしょうか？」あるいは、もう少し実存的不安の響きがする「自分たちを SRE と呼んでもいいでしょうか？」という質問を何度も受けています。 この質問には、すでに、SRE ワークブックの実践リストで答えています。しかし、このリストは「SRE とは何か」については詳しいですが、その理由について詳しく述べていないため、SRE とは何かとい

※この投稿は米国時間 2021 年 5 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。 2021 年用に更新: この投稿には、Google のホワイトペーパー「パスワード管理のベスト プラクティス」のユーザー向けとシステム設計者向けの両方の最新情報を含む、更新されたベスト プラクティスが含まれています。 アカウント管理、認証、パスワード管理には十分な注意を払う必要があります。多くの場合、アカウント管理は開発者や製品マネージャーにとって最優先事項ではなく、盲点になりがちです。そのため、ユーザーが期待するデータ セキュリティやユーザー エクスペリエンスを提供できていないケースがよくあります。 幸い、Google Cloud には、ユーザー アカウント（ここでは、システムに対して認証を受けるすべてのユーザー、つまりお客様または内部ユーザー）の作成、安全な取り扱い、

※この投稿は米国時間 2021 年 3 月 4 日に、Google Cloud blog に投稿されたものの抄訳です。 オンライン クレジット カード決済への移行が進む中、リアルタイムでアクションにつながるアラートを送信する効果的な不正検知ソリューションへのニーズが高まっています。こうした状況を受け、Google では、世界中の金融機関との業務経験を持ち、受賞歴もある Google Cloud プレミア パートナー、Quantiphi と連携し、Google Cloud のサーバーレス NoOps プロダクトを使って 1 時間でスケーラブルな不正利用リアルタイム検出ソリューションを構築できる、スマート アナリティクス デザイン パターンを開発しました。不正利用通知の設定に加えて、不正利用検知パイプラインのパフォーマンスをモニタリングするためのダッシュボードを構築する方法もご紹介します。 こ

Send feedback Compare AWS and Azure services to Google Cloud Stay organized with collections Save and categorize content based on your preferences. Last updated: May 24, 2024 This table lists generally available Google Cloud services and maps them to similar offerings in Amazon Web Services (AWS) and Microsoft Azure. You can filter the table with keywords, such as a service type, capability, or pr

※この投稿は米国時間 2021 年 2 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。 サイト信頼性エンジニアリング（または DevOps）を実装すると、魔法のようにすべてが改善されると思う人もいるでしょう。組織に SRE のおまじないをかけるだけで、サービスの信頼性と収益性が向上し、IT やプロダクト、エンジニアリングの各チームの誰もが満足すると。 このような勘違いが起こる理由は明らかです。世界屈指の信頼性と拡張性を誇るサービスのいくつかは、SRE チームの支援を得て稼働しているからです。Google がその代表的な例です。 私は、大規模な本番環境システムの稼働に明け暮れる生活を 20 年近く続けてきました。トレードオフ、信頼性、コスト、制約や要件が異なる多様なアーキテクチャの実装といったことで頭を悩ませ、深夜に呼び出されることもよくありました。最近では

※この投稿は米国時間 2020 年 12 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。 Cloud Run に対する Google のビジョンはシンプルです。デベロッパーのソースコードを、HTTPS で保護されたドメイン名を使用したフルマネージドの自動スケーリング インフラストラクチャ上で実行できるようにすることです。しかし、従来は、Cloud Run へのデプロイには少なくとも次のような 2 段階のステップが必要でした。 コードをコンテナ イメージへとパッケージ化する このコンテナ イメージを Cloud Run にデプロイする コンテナ イメージはソフトウェアのパッケージ化、デプロイ、スケーリングの業界基準となったものの、すべてのデベロッパーがコンテナの仕組みや、（それぞれの好みの言語で書かれた）アプリをコンテナ イメージへとビルドする方法を知りたい

※この投稿は米国時間 2020 年 12 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。 サーバーレス コンピューティングを導入するとインフラストラクチャを意識する必要がなくなるため、デベロッパーは優れたアプリケーションの構築に専念できます。Google Cloud Platform は Cloud Functions、App Engine、Cloud Run の 3 つのサーバーレス コンピューティング プラットフォームを提供しており、いずれもサーバー管理不要、事前プロビジョニング不要、自動スケーリング、使用したリソースのみの支払いというメリットがあります。 サーバーレス アプリケーションはすばやく簡単に提供を開始できますが、長期間にわたって動かし続けるには継続的インテグレーションと継続的デリバリー（CI / CD）のシステムが重要です。ところが CI

※この投稿は米国時間 2020 年 10 月 29 日に、Google Cloud blog に投稿されたものの抄訳です。 デベロッパーとしてはソースコードを使用しますが、本番環境システムではソースを実行せず、実行可能なものが必要となります。かなり以前から、ほとんどの企業は Java EE（別名 J2EE）を使用しており、本番環境にデプロイする実行可能な「もの」は「.jar」、「.war」、「.ear」ファイルでした。これらのファイルはコンパイルされた Java クラスから構成されており、JVM 上で実行される「コンテナ」の内部で実行されていました。使用しているクラスファイルが JVM およびコンテナと互換性がある限りアプリは機能し、管理は不要です。 JVM ではない Ruby、Python、NodeJS、Go などが構築で使用され始めるまで、これらはすべてまったく問題なく機能していました

※この投稿は米国時間 2020 年 10 月 30 日に、Google Cloud blog に投稿されたものの抄訳です。 企業がアプリケーションやサービスのクラウドへの移行を進めていくと、デベロッパーは日々の問題を解決する最適なソリューションを特定するために、頻繁に新しいテクノロジーを評価、テストすることになります。この評価プロセスには、アプリケーションをホストまたは移行するプラットフォームの特定、API を使用して新しい機能を実装する方法の把握といったタスクが含まれることがあります。 ただし、この初期評価フェーズでは次のようなことを行うために想定よりも長い時間を費やすことが少なくないと、お客様から伺っています。 開発環境の設定 適切なライブラリと依存関係の特定 ドキュメント、統合開発環境（IDE）、ターミナル、Google Cloud Console の間の切り替え また、このような構

※この投稿は米国時間 2020 年 9 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。 DevOps Research and Assessment（DORA）チームが実施した 6 年間の研究から、ソフトウェア開発チームのパフォーマンスを示す 4 つの指標が確立されました。 デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度 変更のリードタイム - commit から本番環境稼働までの所要時間 変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%） サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間 概要レベルでは、デプロイの頻度と変更のリード時間は速度の指標であり、変更障害率とサービス復元時間は安定性の指標です。チームはこれらの値を測定し、継続的に改善を繰り返すことで、ビジネス成果を大幅に向上させることができま

※この投稿は米国時間 2020 年 9 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。 コードを開発マシンから本番環境へ直接デプロイすると、思いがけない問題につながることがあります。コードにローカルの変更内容が含まれる可能性がある、手動で処理されエラーが発生しやすい、テストが省略されるといった問題です。また、実際に本番環境で実行されているコードを後で特定できなくなることもあります。このような事態を避けるためのベスト プラクティスは、ソース リポジトリのブランチに変更が push されるときにコードを継続的にデプロイすることです。 Google Cloud Next ‘20: OnAir で発表しましたように、Cloud Run で継続的デプロイを数クリックで設定できるようになりました。Cloud Run のユーザー インターフェースから Git リポジトリ

※この投稿は米国時間 2020 年 9 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。 AI を活用したアプリの構築は大変な場合があります。私がさまざまな苦労に耐えてきたのは、AI の使用によるメリットには苦しむだけの価値があることが多いからです。よく言われるように、努力は無駄にならないのです。 幸いにも、使いやすいツールのおかげで、この 5 年間で機械学習を使用した開発ははるかに簡単になりました。最近では、機械学習モデルの構築と調整にはほとんど時間をかけず、従来のアプリ開発に多くの時間をあてています。 この投稿では、簡単に使えるお気に入りの Google Cloud AI ツールをいくつかご紹介し、AI を活用したアプリをすばやく構築するためのヒントをお届けします。では早速始めましょう。 事前トレーニング済みモデルを使用する機械学習プロジェクトで特に面倒で

※この投稿は米国時間 2020 年 5 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。 Google Cloud をご利用のお客様から、Google Cloud、他社のクラウド、オンプレミスの指標とログを 1 か所で把握したいというご要望が寄せられています。これにお応えするため、Google Cloud は Blue Medora と提携して、お客様のログを 1 か所で管理し、時間とコストを節約するための単一のソリューションを提供いたします。 Google Cloud のオペレーション管理スイートは、社内と Google Cloud のすべてのオブザーバビリティを支えているスケーラブルなコア プラットフォームをそのまま提供します。Blue Medora の BindPlane ソフトウェアを追加することで、指標とログを収集し、Google Cloud のコア

Accelerate your digital transformation Whether your business is early in its journey or well on its way to digital transformation, Google Cloud can help solve your toughest challenges.