What are Cloud Databases?

Summary

このビデオスクリプトでは、クラウドデータベースの基本とその利点を紹介しています。データセンターの分散化により、データ復旧やスケーラビリティの利便性が強調されています。また、開発者がMVPを開発し始めた際に、クラウドデータベースの利用がどのように役立つかについても触れています。スクリプトは、データベースの種類やバージョンの選択、デプロイメントオプション、そして災害復旧計画の重要性を解説しています。

Takeaways

• 🌐 クラウドデータベースの基本：「Database as a Service」(DaaS)は、世界中の異なる地理的リージョンにあるデータセンターを活用し、サービスを分散させたり負荷バランスをとることができます。
• 📚 使いやすさ：クラウドプロバイダーを通じて、さまざまなデータベース技術を簡単にオンボードし、使用することが可能です。
• 🔄 バージョン管理の容易性：異なるバージョンのデータベースが利用可能で、メンテナンスの負担が軽減されます。
• 🚀 デプロイメントの柔軟性：「共有」または「専用」リソースを簡単に追加でき、必要に応じて「ベアメタル」オプションもあります。
• 🔒 障害復旧とスケーラビリティ：データの1クリックでの復元が可能で、アプリケーションの高可用性アーキテクチャが抽象化されています。
• 👷‍♂️ SREの視点：開発者からSREへのロールチェンジで、クラウドデータベースの運用に関する新たな課題に直面します。
• 🛠️ 開発モードからの移行：MVPの開発時に1つのインスタンスから始め、プロダクションへの移行時にはスケーラビリティと高可用性に備える必要があります。
• 🌍 地理的分散：クラウドデータベースを利用することで、世界各地のユーザーに対応するインスタンスを簡単に設定できます。
• 🔧 障害復旧計画：事前に計画された障害復旧とワークフロー、スクリプトを備えることで、災害発生時の対応が可能になります。
• 🔄 多様なデータベース技術の活用：ポリグロットアーキテクチャの時代において、SQLとNoSQLの両方のデータベース技術を活用することができます。
• 📈 開発プロセスへの組み込み：MVPの開発過程でクラウドデータベースを活用することで、時間の節約とスケーラビリティの確保が可能です。

Q & A

クラウドデータベースとはどのようなサービスですか？

クラウドデータベース、またはDatabase as a Service (DaaS)は、クラウドプロバイダーが提供するデータベースサービスで、異なる地理的な場所にあるデータセンターを利用して、分散型またはロードバランスされたデータベースサービスを提供します。

クラウドデータベースの利点は何ですか？

クラウドデータベースの利点は、使いやすさ、異なるデータセンターにまたがるデータベース技術のオンボードの容易性、バージョン管理の容易性、デプロイメントオプションの柔軟性、ディザスターリカバリーとスケーラビリティの組み合わせです。

クラウドデータベースのデプロイメントオプションには何がありますか？

クラウドデータベースのデプロイメントオプションには、共有リソースと専用リソースの使用があります。共有リソースは低トラフィック時にコスト効率が良く、専用リソースは独自のハードウェアでデータストレージアプリケーションを実行することができます。

ディザスターリカバリーの重要性は何ですか？

ディザスターリカバリーは、問題が発生した場合にデータが1クリックで復元できるようにすることで、データの損失やダウンタイムを最小限に抑えることができる非常に重要な機能です。

クラウドデータベースを利用する際の課題とは何ですか？

クラウドデータベースを利用する際の課題は、個々のデータベース技術のハイブリッドモデルを学ぶ必要性、スケーラビリティオプションの理解、そして障害が発生した場合の備え方です。

MVP開発者がクラウドデータベースを利用する際のアドバンテージは何ですか？

MVP開発者がクラウドデータベースを利用する際のアドバンテージは、使いやすさ、多様なデータベースタイプの利用、スケーラビリティの容易性、そしてデプロイメントから本番環境への移行の際の柔軟性です。

クラウドデータベースのスケーラビリティとは何を意味しますか？

クラウドデータベースのスケーラビリティは、開発者がアプリケーションのトラフィックが増加した際に、データベースを簡単に拡張できる能力を指します。

クラウドデータベースサービスを利用する際のセキュリティ上の考慮点は何ですか？

クラウドデータベースサービスを利用する際のセキュリティ上の考慮点は、データの保護、アクセス制御、およびプロバイダーのセキュリティ基準の確認です。

クラウドデータベースサービスを利用する際のコスト管理には注意すべき点は何ですか？

クラウドデータベースサービスを利用する際のコスト管理には、リソースの使用量に応じたコストの可視化、料金プランの選択、およびコスト最適化の戦略の実施が重要です。

クラウドデータベースサービスがグローバルなビジネスにどのように役立つか説明してください。

クラウドデータベースサービスは、グローバルなビジネスにおいて、地理的な場所に関係なく高速なデータアクセスを提供し、データセンターの地理的分布を利用して、遅延を最小限に抑えることができるため役立ちます。

クラウドデータベースサービスを利用する際のバックアップ戦略とは何ですか？

クラウドデータベースサービスを利用する際のバックアップ戦略は、定期的なバックアップの生成、バックアップのスケジュールや種類（完全バックアップや増分バックアップ）の選択、そしてバックアップの保存期間の設定です。

Outlines

00:00

😀 クラウドデータベースの基本と利点

この段落では、クラウドデータベースや「Database as a Service」(DaaS)の基本について説明しています。クラウドプロバイダーは世界中の異なる地理的場所にデータセンターを持ち、分散型またはロードバランスされたサービスを提供しています。これにより、使いやすさが得られ、異なるデータベース技術を簡単にオンボードして使用できる利点があります。また、異なるバージョンのデータベースも利用可能です。デプロイメントに関しては、共有または専用のリソースを使用するオプションがあり、「ベアメタル」と呼ばれるものもあります。ディザスターリカバリーとスケーラビリティも重要なポイントで、データの1クリックでの復元が可能で、アプリケーションの高可用性アーキテクチャが隠された形で提供されています。しかし、これらはSREの観点からの課題にもつながります。開発者がクラウドデータベースを使い始めると、使いやすさ、スケーラビリティ、ディザスターリカバリーの各利点を利用して、アプリケーションを効果的に開発することができます。

05:04

😉 クラウドデータベースを使った開発プロセス

2つ目の段落では、開発者がクラウドデータベースをMVPの開発プロセスで使用する理由とその利点について語っています。開発者は使いやすさから、さまざまなタイプのデータベースを簡単に実装して使用できます。デプロイメントはスケーラビリティの観点から優れており、開発者は小さな規模から始め、MVPから本番環境への移行時にスケールアップして高可用性を実現できます。ディザスターリカバリーは開発の初期段階からすでに考慮されており、開発者はアプリケーションが負荷下でどのように機能するかを理解するためにユーザーを増やすことが重要です。また、グローバル経済においてアプリケーションを利用するユーザーが世界中にいるため、地理的な配慮も必要で、クラウドデータベースサービスを利用することで、地理的に分散したインスタンスを設定することができます。最後に、クラウドデータベースを使用した経験やアーキテクチャのヒントについて共有を呼びかけています。

Keywords

💡クラウドデータベース

「クラウドデータベース」とは、インターネット経由でアクセス可能なデータベースサービスのことを指します。このサービスは、データの保存と管理をクラウドプロバイダーが行うため、企業や開発者はデータベースの設置や保守に時間を費やさずに、データの運用に注力できます。ビデオでは、クラウドデータベースの利便性と、データセンターの分散により提供される高可用性、拡張性、および障害復旧機能について語られています。

💡Database as a Service (DaaS)

「Database as a Service」とは、クラウド上で提供されるデータベースサービスを意味し、顧客はデータベースの管理や保守をクラウドプロバイダーに委ねることができます。ビデオでは、DaaSが提供する利便性と、異なる地理的場所に分散されたデータセンターを通じたデータの分散とロードバランスについて説明されています。

💡データセンター

「データセンター」とは、コンピュータシステムとストレージが集中管理される施設です。ビデオでは、クラウドプロバイダーが世界中の異なる地理的地点にデータセンターを持つことにより、顧客はデータのバックアップと障害復旧を簡単かつ迅速に行うことができると強調されています。

💡SRE (Site Reliability Engineering)

「SRE」とは、ウェブサービスやクラウドサービスにおける信頼性と可用性の向上に特化したエンジニアリング分野です。ビデオでは、開発者がMVPを開発した後、SREの役割に変わり、クラウドデータベースの運用と保守に関する責任を持つことが求められると示唆されています。

💡スケーラビリティ

「スケーラビリティ」とは、システムが需給の変化に応じてリソースを拡張または縮小する能力を指します。ビデオでは、クラウドデータベースが提供するスケーラビリティについて触れており、開発者はアプリケーションのニーズに応じて簡単にデータベースを拡張できると説明されています。

💡障害復旧

「障害復旧」とは、災害や障害が発生した場合に備えて、システムの回復力を確保するための計画やプロセスです。ビデオでは、クラウドデータベースが備える障害復旧機能が強調されており、データのバックアップと迅速な復旧が可能であると述べています。

💡デプロイメント

「デプロイメント」とは、ソフトウェアやシステムを運用環境に展開するプロセスです。ビデオでは、クラウドデータベースサービスが提供するワンクリックでのデプロイメント機能について触れており、開発者は簡単にデータベースを立ち上げることができると説明されています。

💡共有リソース

「共有リソース」とは、複数のユーザーが同じリソースを共有して使用するモデルです。ビデオでは、クラウドデータベースにおいて共有リソースを使用することで、開発者は初期段階でコストを抑えつつデータベースを利用できると紹介されています。

💡専用リソース

「専用リソース」とは、特定のユーザーまたはアプリケーション専用に割り当てられたリソースです。ビデオでは、専用リソースを使用することで、開発者はより高いパフォーマンスとセキュリティを確保できると強調されています。

💡分散型アーキテクチャ

「分散型アーキテクチャ」とは、異なるコンポーネントが異なる場所に分散配置されているシステムアーキテクチャです。ビデオでは、開発者が分散型アーキテクチャを用いて、アプリケーションを複数のデータセンターにわたって展開し、グローバルなユーザーニーズに対応する戦略について説明されています。

Highlights

Congratulations on transitioning from MVP development to the role of an SRE.

Introduction to the top five technologies in the SRE bucket, starting with cloud databases.

Definition and explanation of 'Database as a Service' (DaaS).

Advantages of cloud providers' global data centers for load balancing and ease of use.

Ease of use in cloud databases across various data centers regardless of SQL or NoSQL technologies.

Availability of different database versions for immediate use, reducing maintenance concerns.

Deployment benefits with a variety of options including shared and dedicated resources.

Explanation of 'bare metal' and its role in database deployment.

The cost-effectiveness of shared resources for low-traffic applications.

The benefits of dedicated hardware for data storage applications.

Importance of disaster recovery and scalability in cloud databases.

One-click restoration for disaster recovery and automated backup schedules.

High availability architecture in cloud databases, abstracted for user convenience.

Challenges faced by SREs when adopting cloud databases for MVP applications.

The necessity of understanding different database technologies' highly available models.

Incorporating chaos engineering to prepare for disaster scenarios in MVP applications.

The time-saving aspect of cloud databases in the development process.

Strategic use of cloud databases from the MVP phase to production for scalability.

Global considerations for application deployment using cloud databases to improve response times.

Invitation for sharing experiences and tips on using cloud databases and DaaS.

Transcripts

From ideation to development of your MVP,

congratulations!

Because now you got to switch your hat to becoming an SRE.

And top five of my technologies in my SRE bucket

are cloud databases.

But before we unpack that particular term,

let's take a moment to break down

what's kind of the fundamentals of a cloud database

or as you may see online, "Database as a Service" (DaaS).

Well, we know with cloud providers you're going to have different data centers

located in different geographies around the world,

which is why we love working with them,

and all their services are dispersed

or actually load balanced worldwide

across all these different data centers.

So you get to take advantage of that particular ease first.

Now, in the context of databases,

first thing we're going to have is that ease of use.

So across all of these data centers,

you have easy ways - depending on the database technology -

an easy way to onboard and use that particular technology.

And that's particularly effective

if you are working with multiple databases.

And they can be of course, noSQL or SQL ones there, all right?

There's always going to be something that you can have.

And also different versions of the databases will be available for you to use.

So I like to throw that into the maintenance part,

being able to say you have to worry about versions or

it's all available for you to use.

Second, on top of my list that I love is the deployment.

There will be multiple deployment options at your ease.

Add a button, click to use.

Most notably, you'll have "shared",

or dedicated resources that you can use,

and you may see that mixed in with the term called "bare metal",

shared is where you're actually sharing with others.

Just to quickly get going,

when you have low, low traffic is kind of good to get going, especially from a cost perspective.

But there's nothing like being able to have that option to execute

your own dedicated hardware to running your particular

data storage application.

The storage portion of your own architecture that you have.

And lastly, disaster recovery and scalability.

That's got to put those both into the same bracket.

From the perspective that we all know what disaster recovery is:

when things do occur, we don't have to take that, alleviate that concern off our mind,

because the data will be able to be restored with one click.

Usually backups are being generated on some schedule,

usually nightly or incremental.

For database, for database backups, we have that there.

And also, already deploying the application to be in a

highly scalable manner,

a highly available manner where you have your primary, secondaries,

all that architecture gets obfuscated from you

where it's just available for you to use.

And this all sounds great,

but this does actually map out to our concerns,

our challenges that we have once we put on that SRE hat.

So I've built my application that I know.

Let's take the perspective that I'm just starting out.

We know that we spent a lot of time building our application.

And that's generally been from the perspective of,

I've gotten started, I said, "hey, I just want one instance of this",

whether it's a SQL or a no SQL,

we are in the age of polyglot architectures.

So a lot of my architectures start out with both types

depending on the demands of my application or what I need to do,

but I really, focusing on time that my perspective was different when I was in my development mode.

I'm just concerned with getting it up and running.

I usually worry about the other stuff later,

if I'm actually the person that deals with that.

Usually that can be somebody else's perspective to actually deal with it too,

if you have different job roles.

But as a full stack developer and as technologists,

when you're in the full stack mode, you have to always make these decisions,

but our goal is to get that up and running and to actually know what's there.

Secondly, is the scalability of options there.

Without cloud databases, or including that you have to learn

the individual ways that each database technology goes on their particular highly available model.

So I did the primary, secondary, you know there's different architectures,

different concerns for each that you have to be aware of to work.

And lastly, what we all dread in our MVP applications is chaos occurring, all right?

You have to definitely have concerns about preparing what happens when something disastrous occurs.

We can force things to happen with chaos engineering, that's where we generally like to know.

But I want to say when the chaos occurs, what do we do?

We have to know about our own disaster recovery and how to function, have workflows, have scripts for this.

And when you think about all these three perspectives,

there is an exactly even more time that we have to dedicate, to this perspective.

But we know that our time should be really dedicated

to evolving our code, doing new releases,

especially when you have a combination of front end technologies, all right?

You have web.

And you have mobile.

Mobile apps that we have,

that's not a good looking iPhone there, but that's what is intended to be, iPhone there.

So different perspectives, APIs.

There's a lot of technology you can kind of get into that come into play here.

So we can alleviate all these challenges

once we get that hat on by saying,

"hey, cloud database is where I should be."

And often this is where I actually start

in my development process while I'm building my MVP,

I'll start working with my cloud databases.

You may say, why would you do that?

Well, first, from a time perspective, I'll have that ease of use.

I actually will be able ... I will actually be in an advantage to use or think about using more types of databases

because they're going to all be available to me, all right?

And I could easily implement them

and get going without having to learn

each different technology's way of connecting and everything there.

Secondly, the deployment,

it takes care of my scalability concerns

because now I can start out small while I'm in development.

One instance well, how we always know we start, let's keep it honest, all right.

And then, and when I want to get ready to go from MVP

to production, I can scale that up and immediately become highly available.

All right.

And lastly, disaster recovery, already there for me.

We know we have to plan for this.

As we start out in development, we're just trying to get things running.

We don't have time to really think about what could happen,

but our goal is to have more users using our application

because that's where we understand how it's going to function under load.

And you may have other certain requirements as well.

We know that we're in the U.S., we build applications, but we know we're in a global economy now.

People from around the world will be using your application.

So there may be other concerns.

I may want to have users in Singapore or in India or somewhere

where if the servers are located on my own and I'm in the US,

there is a certain round trip

- or Australia, you know, there is something you can't deny,

it has to travel that far.

So, response times may be slow.

Well, using this I'm able to set up

different instances in those places, or just let the database as a service

spread out my data across its actual geo sensors.

This is just one way to think about this perspective.

I want to hear about your experiences

with cloud databases, or database as a service.

Tell us about your favorite ones to use, your architecture tips.

And as always, technically yours, Señor España.