セキュリティアーキテクチャの概念は、かつてのメインフレームの時代からハイブリッドクラウド（オンプレミスとクラウドの併用）およびマルチクラウドへの移行に伴い、大きく変化しました。技術プラットフォームが複雑化し、適用すべきセキュリティポリシーが増大する環境下において、効果的なセキュリティを設計することは非常に困難です。本書では、ハイブリッドクラウドの複雑性に対応するため、ゼロトラスト原則やデザイン思考、アジャイル、DevSecOpsなどと統合した、アーキテクチャ思考プロセスを解説します。学習を支援するためのケーススタディや、図表などの成果物とともにアーキテクチャ思考を解説し、読者がセキュリティをシステムに組み込むことで価値ある資産を効果的に保護できるようにします。 『実践 ハイブリッドクラウド・セキュリティアーキテクチャ』への賛辞 まえがき 第Ⅰ部 理論 1章 はじめに 1.1 基本的なセキュ
※この投稿は米国時間 2022 年 7 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。 Kubernetes にデプロイしたアプリケーションは、サービス アカウントとして実行されます。サービス アカウントとは、Kubernetes コントロール プレーンによって理解されるシステム ユーザーです。サービス アカウントは、アプリケーションにどのような操作を許可するかを構成するための基本ツールであり、単一マシン上のオペレーティング システム ユーザーの概念に似ています。Kubernetes クラスタ内でロールベースのアクセス制御を使用して、サービス アカウントに許可する操作（「すべての Namespace 内の Pod を一覧表示する」、「Namespace foo の Secret を読み取る」）を構成できます。Google Kubernetes Engine（
はじめに LayerX Fintech 事業部から、三井物産デジタル・アセットマネジメント(以下、MDM) に出向している piroshi です。 AI 活用や業務自動化が当たり前になってきた今、データや処理はプラットフォームをまたいで動くことが増えています。特に「システム基盤はAWSで動かしつつ、社内業務は Google Workspace 前提」といった構成では、AWS 上のワークロードから Google Cloud(以下、GCP) や Google Workspace の API へ安全にアクセスしたい場面が自然に出てきます。 MDM でもそのニーズが顕在化しました。具体的には、共有ドライブの構成情報を定期的に取得して監査(権限・設定の棚卸し)を自動化したい、という要件があります。加えて、別のチームでは Google Drive 上のリソースにアクセスする業務ツール開発も並行して進ん
本記事は ネットワークウィーク 4日目の記事です。 💻 3日目 ▶▶ 本記事 ▶▶ 5日目 🌐 はじめに 対象読者 この記事で伝えたいこと すべての基本：AWSとGoogle Cloudの「思想の壁」 主要サービス比較：AWSの知識をGoogle Cloudに置き換えて理解する 1. 仮想ネットワーク (VPC) 2. サブネット 3. ファイアウォール 4. ロードバランサ + CDN AWS経験者が意識すべきポイント おわりに はじめに クラウド事業推進部の小野内です。ネットコムに入社して、もうすぐ3年半となります。 多くのインフラエンジニアにとって、AWSのネットワーク構成はもはや共通言語と言っても過言ではないでしょう。VPC、サブネット、セキュリティグループといったコンポーネントを組み合わせて、要件に合わせたネットワークを設計するのはおなじみの作業かと思います。 しかし、いざG
AWS、Redisをフォークした「Valkey」をAmazon ElastiCacheとAmazon MemoryDBで提供開始
Amazon Web Services（AWS）は、Redisをフォークしたインメモリデータベース「Valkey 7.2」をAmazon ElastiCacheとAmazon MemoryDBで提供を開始したことを明らかにしました。 Valkeyのフォーク元となったRedisはオープンソースとして開発されてきましたが、今年（2024年）3月、ライセンスをクラウドベンダなどによる商用サービスを制限するものに変更したことでオープンソースではなくなりました。 このライセンス変更を受けてAWS、Google Cloud、Oracleなどを始めとする複数の企業がLinux Foundation傘下でRedisをフォークし、オープンソースとして「Valkey」の開発を始めたのです。 そして9月にはGoogle CloudがValkeyのマネージドサービスをプレビュー公開し、AWSもマネージドサービスと
Googleが公開した、MLOps実践のためのホワイトペーパー GoogleがMLOps実践のためのホワイトペーパーを公開しています。 Practitioners Guide to Machine Learning Operations (MLOps) 2021年5月に公開されたものですが、2024年現在に読んでも色褪せない内容だったので、各章の要点をまとめました。 TL;DR Googleが2021年5月に公開したMLOpsの実践のためのホワイトペーパー MLOpsライフサイクルの全体像・コア機能を解説 コア機能: 実験、データ処理、モデル学習、モデル評価、モデルサービング、オンライン実験、モデル監視、MLパイプライン、モデルレジストリ、データセット・特徴量レポジトリ、MLメタデータ・アーティファクトトラッキング MLOpsのコアプロセスの詳細を解説 コアプロセス: ML開発、学習の運用
まいど AWS の犬が、少々 Azure に触れてみましたので、絵は描かずに基礎知識の整理と共有だけしていきたいと思います。 全然ド素人な状態なので、なにかしら間違ってたり不足していると思われますが、同じようにイチから調べる人の足がかりにでもなれば、くらいの質感で進めていきます。 はじめに 今のところ少々用事があっただけなので、これから Azure を掘り下げるぞとか、Azure の犬になるぞ、とかは考えていなく一発ネタで終わる可能性が高いです。雑なメモをブログに起こして、いったんの区切りとする個人的な清書のため、詳しくはちゃんとリンク先のドキュメントなどを読んでくださいませ。 さて、AWS に似たパブリッククラウドはいくつもあり、Azure もその１つです。公式ドキュメントに何箇所も AWS との比較が出てくるくらいには、Azure も AWS を意識しています。 例）AWS サービスと
最近、分散データベースとかNewSQLとかサーバレスなデータベースとか色々聞きますよね。 でも、専門ではない人たちにとって、「何が違うの？」「自分たちに必要なDBはどれなの？」という点が分かりづらいと思います。 私も良く聞かれます。 AuroraはNewSQLですか？ NewSQLってサーバレスなんですか？ スケールできないDBとか聞きますけど、リードレプリカ増やせますよね？ などなど。この辺に基本的なところから答えられるように、順を追って解説していきましょう。 「コンピュートとストレージは別であれ」 と神が言うと、コンピュートとストレージは分離された。 と言うのは冗談ですが、まずはここからスタートしましょう。 クラウド以前のデータベースを使っていた人にはお馴染みのように、それまでデータベースは大きな1つの箱でした。 過去に私は下図でデータベース（厳密にはRDBMS）のコンポーネントを解説
Google Cloudで実践！ クラウドネイティブな開発 サービスメッシュを活用して、クラウドアプリケーションのオブザーバビリティを高める 本連載は、Google Cloudのアプリ開発とDBプロダクトにおけるスペシャリスト達が、Google Cloudプロダクトを利用した、クラウドネイティブな開発を実践する方法を解説しています。 第6回では、サービスメッシュについて紹介します。 主に対象となる読者は、クラウドを利用してアプリケーションを開発するエンジニア、またはその基盤を構築するエンジニア、サービス開発に携わるプロダクトマネージャーを想定しています。 マイクロサービスアーキテクチャの課題 これまでの連載ではクラウドネイティブなアプリケーションの開発について紹介しました。小さい独立して動作するサービスが連携するマイクロサービスアーキテクチャは、スケーラビリティ、独立した開発の容易さ、
本稿の趣旨は米国連邦政府のクラウド推進戦略、いわゆる「Cloud First」から始まる一連の政策が辿った経緯を概観することである。米国のクラウド戦略は、掛け声こそ勇ましかったものの、あまりうまくいかなかった。これは筆者の主観ではなく、連邦政府自身がそれを認めるレポートを出している。あとで具体的に見ていこうと思う。 本邦においてもガバメントクラウドが本格的に動き出している。さくらインターネットが政府公認のベンダーとして認証を受けたことが話題になったのはつい最近のことだ。本邦のクラウド戦略もかなり米国のそれを参考にしており、そのまま進むと同じ轍を踏む可能性もなきにしもあらずである（実際には米国と日本では政府の置かれている状況がかなり違うので、一概に米国と同じ道筋を辿るとは言い切れないのだが）。しかし、世界で最も積極的にクラウドを採用した政府がどのような点で成功し、どのような点で苦しんできたか
はじめに 近年、Kubernetesの採用が進む中、複数のチームが関わり、複数のクラウドプロバイダーへのデプロイを行い、異なるスタックを扱う組織では、その導入の複雑さが新たな問題となっています。本書 『Platform Engineering on Kubernetes』は、Kubernetes に登場しつつあるベストプラクティスとオープンソースツールを活用し、これらのクラウドネイティブの問題を技術的に組織的にどのように解決するかを示してくれます。 learning.oreilly.com 本書では、Kubernetes上に優れたプラットフォームを構築するための要素を明確に定義し、組織の要件に合わせて必要なツールを体系的に紹介しており、実際の例とコードを交えながら各ステップをわかりやすく説明することで、最終的にはクラウドネイティブなソフトウェアを効率的に提供するための完全なプラットフォーム
SaaS をアーキテクトをするにあたって、どのような事を考えればよいのか？をまとめました。 このスライドでまとめているのは SaaS とは、ビジネスモデル x 技術であることを理解する SaaS アーキテクトでどのように SaaS を作っていくのか？を考える SaaS KPI で…
※リンクを効かせたい場合はダウンロードしてください
はじめに お久しぶりです、iselegantです。 今回はAWSアーキテクトの目線から、多様なGoogle Cloud Load Balancingの世界を紹介してみたいと思います。 昨今、担当業務やプロジェクトによってはAWSのみならずGoogle Cloudを活用したり、マルチクラウドとして両方扱うエンジニアの方も多くなってきたのではないでしょうか？ 特に、SI企業に所属する人においては、担当プロジェクトや業務、お客様が変われば利用するクラウドサービスも変わる、なんてこともよくあると思います。 私もその道を辿ってきた一人です。 現在ではクラウドサービス間においてもある程度のコモディティ化が進んでおり、ある一つのクラウドサービスに精通すると、他のクラウドサービス利用時におけるメンタルモデルが出来上がり、システムを構築する際に前提の知識や経験が大いに役立つはずです。特にAWSはサービスの幅
はじめに こんにちは、ML・データ部MLOpsブロックの岡本です。 MLOpsブロックでは日々複数のGoogle Cloudプロジェクトを管理しています。これらのプロジェクトでは、データサイエンティストやプロジェクトマネージャーなど別チームのメンバーが作業することもあり、必要に応じてメンバーのGoogleアカウントへ権限を付与しています。 権限の付与はプロジェクトの管理者であるMLOpsブロックメンバーが行いますが、これは頻繁に発生する作業でありトイルとなっていました。 また権限付与後はこれらを継続的に管理し、定期的に棚卸しすることで不要になった権限を削除する必要があります。しかし当初の運用だと権限の棚卸しの対応コストが大きく、これが実施されずに不要な権限が残り続けるという課題もありました。 本記事ではMLOpsブロックで抱えていたGoogle Cloudプロジェクト内での権限管理における
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
