シャドーイング練習: Configure storage accounts | AZ-104 | Episode 16 - 動画で英語スピーキングを学ぶ

練習モードを選ぶ

各モードは全画面の練習ルームで開きます。

375 文

文が短すぎたり長すぎる場合は、Editをタップして調整してください。

Data and the availability of data is the value part of any business proposition that you're working with.

The resources at the underlying ways to deliver that data to you are important, but the data itself is going to be super important to make sure that it's safe,

secure, reliable, and always available.

Azure Storage accounts are going to give us that capability, as well as teach us some several base components

that will allow us to understand how Azure as a whole performs a number of its magical duties.

With that, my name is Bob Tickleman.

I'm excited to be your guide for this module on Azure Storage.

Azure Storage is a foundational tool for the storage of information.

It's going to provide a wide variety of configurations that will meet almost any business requirement that you have.

Where it's going to fall into the categories of unstructured data and lightly structured data.

Highly structured data like SQL is not going to be available.

It's done in specific tools, but you'll see in the storage account, we have the capability to have those two types of storage of unstructured data,

that traditional hard drive that has xls doc doc files you know exes inis

that variety of unstructured data as well as having some lightly

structured data very similar to a table structure you're working with

so we're going to take a look at a deep dive in storage

and by learning these skills

and understanding the deeper components of how they do their work

it will reveal on a whole how azure does a lot of what it does

so with this we're going to take a look at storage accounts the kinds of accounts that are available, and use case scenarios of how to deploy and get the best business value from that.

A storage account is a regionally based unit of storage and replication.

I've been using that line since I've been teaching Azure, and it sounds kind of straightforward to me, and I've said it so many times, it just makes sense.

But I want to stress this again.

An Azure storage account by itself doesn't store anything.

It is a regionally based So we're going to go and take a look at what that means.

So if you have to have store stuff in two different locations, maybe in North America and one in Europe, you would need two different storage accounts, one per region.

Now, if you have two locations in North America, one per region, so you'd have to have one for each region.

So a storage account is a regionally -based unit of replication.

We're going to dive deeper into this

and take a look at the different ways in which Microsoft makes the storage information highly available,

ranging from anywhere from 11 nines to 16 nines of high availability.

So that's 99 .99999999999999999999 times,

which is far beyond what most people look at of the five nines

that we all strive for in our on -premise world.

So a storage account, regionally -based unit of replication.

If you needed two different types of replication, and you'll see that there's multiple types up to six, you're going to have to have two different storage accounts for that.

Okay, so let's go off and do some whiteboarding.

We're going to come back and take a look at how

that gets implemented because I want to understand the base components before we go in

and take a look at the types of storage that can appear in a storage account.

So starting off with that comment about a storage account is a regionally base.

We've seen this map in other recordings where these are the current 67 regions that are available in public Azure.

So if I wanted to store something here in this location, I would need a storage account.

If I needed my application having it in North America in that location, I would have a storage account for it.

Now, we've also shown you in other recordings what a region looks like.

So here is, this is US East, which is our biggest region.

It's our favorite.

You know, it gets everything first.

US East, this picture in the upper right -hand corner is what it looked like in 2014.

Each one of these data centers has its own standalone redundant power,

network connections, air conditioning, cooling, all of that stuff.

And you can actually see different designs, what we call our Gen 1, our Gen 2.

And you'll see that in 2017, we added a significant amount of resources.

So that picture in the upper right is that piece right there.

We've more than doubled the capacity with our advancements in 2017.

And it's changed even since then with these massive data centers that you're working with.

And the reason I show that is because I want to talk about this thing called an availability zone.

And then we're going to go in and take a look at what happens inside of the data center itself.

So an availability zone.

is a way for Microsoft to obfuscate the data center structure.

You don't get to pick a data center.

What Microsoft does is we then balance the load across the region

so that we don't fill up all the resources in one data center.

When it's full, we go to another data center, fill it all up, because it would then provide single points of failure.

What we do by making availability zones available to you, I have blue user who has availability zone 1, 2, and 3.

They have three zones, and what Microsoft will do is we will determine which data centers make up zone 1, 2, and 3.

So for blue user, this one might be 1, this one might be 1, this one might be 1, this might be 1, this might be 1.

Zone 2 is here, zone 2 is here.

We've got a couple of 2s up here.

We've got a 2 here and a 2 there.

Zone 3 might be here, here, here, 3, 3, and 3.

So all of the data centers that make up that region will then be identified for blue user, whether it be a Zone 1, Zone 2, or Zone 3.

So you might get one of your applications in Zone 3 put there, and another one put into a different Zone 3.

But it's now spreading this load across multiple data centers, limiting the potential chance of a single point of failure.

Doing the same thing for green user, they have a zone one, zone two, and three.

Their zone one might be here, here, here.

It might be zone one.

Their zone two. And their zone three.

I'll go into the same one.

Zone three, zone three.

So we'll spread them around that vary from user to user.

It's not the same thing for everybody.

So understand that zonal concept.

Now I'm going into deep dive on this

because this technology is going to be the same thing when we get into a whole nother set of recordings.

Later on, when we take a look at a thing called PaaS

or Platform as a Service and things like app service plans, a lot of those ideas are going to be replicated on this concept of Azure Storage.

So I'm doing a deep dive here.

And when I do those later recordings, I'm going to refer back that someone comes and watches this specific session

because I'm not going to do this in all of them.

I'm not going to repeat that.

But this is going to be a deeper dive.

You know, learn it once and you'll be able to use it many times over.

We saw that within a region, there is one or more data centers.

That's great.

So we're going to take a look at what happens inside of a single data center.

Inside of the data center, we have things that are called scale units.

Now, this is a concept that's probably well beyond what most people need to know.

But I feel, especially as administrators, the more you understand this, the better you're going to be able to guess other topics.

100

What a scale unit does is define a configuration that is deployed to a node set or a group of computers.

101

So we may have a scale unit that is specifically designed for storage.

102

We might have a node set that is going to be configured for compute.

103

And so everything in that scale unit will have a single configuration

104

and we might have multiple scale units of a similar type.

105

Each scale unit then has a term called a fault domain

106

that indicates a single point of failure within the set of scale units.

107

So it's hierarchical.

108

A scale unit has a set of fault domains that make up similarly configured devices, each having a single point of failure.

109

Now, that single point of failure typically becomes a thing called a TOR, or the top of rack switch,

110

that are two of them that are redundantly connected back into the backbone of the Nazar's communication.

111

We have the PDUs, or the power distribution units, that again are redundantly connected to all of the nodes that are on that scale unit.

112

Inside of them, we have nodes.

113

We've got node 1, node 2, node 3, node 4, and so on.

114

So a scale unit has these, and they have, I've put Windows in there, we actually have our own operating system, I'll call it Azure, that is deployed to these nodes.

115

Now let's take a look at how this comes into play.

116

A storage account is a regionally based unit of replication.

117

I have a file.

118

I've got bob .doc.

119

That file is going to connect to a thing called a resource provider.

120

Now, if you saw the recordings, you would have seen this diagram.

121

I have my bob .doc, that if I'm looking at that file, it is accessed

122

and we saw in other recordings there's different ways through the

123

graphical interface through clis bash command line tools you're going to connect to this case the storage resource provider

124

and we saw again in a networking component

125

that we talked about creating a service endpoint

126

so storage is an azure service now i've talked about in other modules as well some golden rules

127

that appear at microsoft in general child objects inherit things from

128

the parent go see those modules permissions are cumulative with the

129

exception of deny again talked about in security modules here all

130

data in azure is stored a minimum of three times I

131

don't care what it is a minimum of three times

132

so what will happen is my bob .doc however I've decided

133

to store it is going to hit the storage resource provider

134

and here's the eye -winking moment the thing it is synchronously connected to all three copies.

135

So someplace in Azure, there's going to be three full copies of that bob .doc file.

136

This is not RAID.

137

It's not redundant array of independent

138

or inexpensive disks where we're putting portions of it across multiple disks so that if one fails, we have three distinct copies that are synchronously connected.

139

And if I make a change, it is synchronously connected to those three copies.

140

Now, we're going to refer to that term called LRS, or Locally Redundant Storage.

141

You'll see this when we get back to the PowerPoint slides.

142

But LRS synchronously connects to those three copies, and we're going to then see how that plays out in the data centers itself.

143

So I've got my bob .doc connects to the resource providers, and it's now going to write three copies of

144

that bob .doc file someplace into an LRS locally redundant storage into a single data center inside of the region.

145

So as I'm drawing this, I'm hopefully some of you are thinking like, Bob, what are you doing?

146

I've now put those three copies into the same fault domain.

147

This is not a good thing because

148

if the TORs go down I lose the entire scale unit meaning I lose access to my three copies.

149

So that's not what happens.

150

I want some of you

151

while I clean up here I want you to think of what you think is going to fix this problem.

152

What it does instead of writing three copies into the same three fault domain inside of the same data center, it's gonna spread it across three fault domains.

153

And this is where those 11 nines of high availability starts to come.

154

I've now got bob .doc across three different fault domains so that if I do end up losing a single fault domain,

155

I still have multiple copies of that information.

156

Now be careful, this is not a form of backup.

157

It is high availability because if I make a corrupting change to the bob .doc document,

158

remember, it's going to synchronously make that corrupting change against all three.

159

This is not a replacement for backing up.

160

It does not guarantee a point in time recovery back to your data.

161

Well, maybe I'm going to give you some examples of that.

162

But by itself, a storage account is just for high availability across the three fault domains you're working with.

163

So you're going, well, that's really good, Bob.

164

But what happens if I lose an entire data center?

165

Which could happen.

166

It happens infrequently.

167

And I know of one back in 2018.

168

One of our data centers in south -central U .S., if you're familiar with that geographic area, sometimes called Tornado Alley,

169

a single data center was hit with over 19 strikes of lightning and took an entire data center off.

170

But the rest of the region was up and running

171

so what we now do we give you an option instead

172

of lrs we give you an option for zrs zone redundant

173

storage i still have my bob .doc file this time it's a green one it's still within the same region

174

but now it's going to go to a zone and i still have three copies but now those three copies

175

are across three zones within the region

176

and this way i could potentially lose an entire data center and still have access to my resources in that region.

177

Pros and cons.

178

You're going, Bob, why don't I use, you know, ZRS everywhere?

179

Well, the problem with ZRS in some cases is there's potentially

180

a sub two millisecond latency between the communications of all the data centers within that region.

181

you don't get that level of latency potentially in an LRS solution because they are very close together, connected by fiber channels.

182

So Microsoft guarantees sub two millisecond latency for those copies to be synchronized across the region.

183

Well, what happens if I lose the entire region?

184

Well, guess what we have?

185

These people have thought of everything.

186

We've talked about LRS, which then puts your three copies into three different fault domains within a single data center.

187

We've taken a look at ZRS.

188

That's going to put your three copies across three different zones, but within the same region.

189

There is an option to have GRS and GZRS, globally redundant storage.

190

So now what it's going to do in the case of LRS, I should maybe put that letter back in, LRS not only copies three copies redundantly,

191

synchronously across the same data center, it now takes into a region pair.

192

Going back to that map, remember Microsoft pairs our region.

193

US East is paired with US West.

194

US East 2 is paired with US Central.

195

So if you set up GZRS or GRS for Globally Redundant Storage, it now takes three copies and async,

196

asynchronously replicates those copies, three in another region that is paired.

197

You don't get to pick this.

198

It's the region pair picked by Microsoft.

199

Now, this async, Microsoft talks about a delta potential difference of up to 15 minutes.

200

Again, it's not instantaneous know that there's a point in time

201

that it will replicate that stuff across to that other paired region.

202

Now, I'm not going to get into all the details.

203

This also provides high availability that if the entire region goes down,

204

what Microsoft will do is say if you had a www page that referenced the IP address,

205

if you go take a look at the networking modules where we took a look at things like application gateways, if you had an application gateway accessing the data here,

206

What Microsoft will do is we will then reroute

207

that to the globally redundant data that's running that application in the other region,

208

knowing that there may be information that might be out of sync.

209

So what we often recommend for this type of replication on a global basis is

210

that you make it data that changes infrequently.

211

I wouldn't use it for database replication.

212

You know, there's other and better methods to do that, but for read -only files or information that changes infrequently,

213

and you could live with potentially losing some of that in the case of a significant outage and the automatic failover features.

214

So we're going to go back and take a look at some of these, but know that there's multiple types of replications that a storage account can have.

215

And if you wanted one or more of these, you would have to have one or more storage accounts because a storage account is a regionally -based unit of replication.

216

Now, we don't have time for it in the entirety of this class, but there's also gonna be a few features

217

that I'll show you in the live demo

218

that you now can actually replicate some or all of a storage account to any other region of your choosing.

219

It's not gonna be the level of a storage account.

220

It's gonna be up to you to manually say, oh, this container in this storage account, I want that information maybe over in Europe you can set up manual replication of

221

that information that will be done on a regular interval, but it's not part of the normal storage account infrastructure.

222

So hopefully that has helped you with understanding the components and how they work from a replication perspective.

223

So with inside of Azure, the storage account has different types of data that it can work with.

224

We have containers and files.

225

These are what we call unstructured data.

226

Unstructured data, as I've described, that's your traditional hard drive that has EXEs, MP3s, DLLs, INIs.

227

It's got your .docs.

228

It's got this unstructured set of data in whatever format kind of randomly spread across it.

229

Now, those containers store what are called blobs or binary large objects.

230

We're going to get into more of this in a few minutes, and you can see there are images, documents, videos, audio, all of that information.

231

Now blobs or binary large objects are a new format to be able to store this

232

and they can be massive in size.

233

Some of you probably ran into a four gigabyte size limit in the old file share models that you were working with.

234

Blobs are more of a new modern method to do this

235

and it uses an HTTP or an HTTPS method to actually access that information.

236

That's an eye -winking moment for you if you're going to take the exam.

237

If you get a question saying, you're looking to access information over an HTTP request, that information should be stored in containers or blobs.

238

Files and file shares go back to that traditional file service management system that you're used to.

239

And it has directories you're working with, and it uses a thing called SMB or server message block.

240

This is secured communication, and it's very fast from a protocol perspective, but know that there's a difference between the protocols themselves.

241

Again, it has a wide variety of unstructured data that you're working with.

242

Tables and queues become this lightly structured data.

243

I'll show this in the live demo.

244

We're not going to get too deep into it, but tables provide what are called name -value pairs.

245

They can be used to store lightly structured data.

246

If you're used to this, you might have heard terms like MongoDB, Gremlin, Cassandra, lightly structured data.

247

And I'll use the example of it's like an Excel document.

248

It's got rows and columns with name value pairs.

249

The name of first name, the column header, has these values.

250

Last name, these attributes, so those name value pairs.

251

Queues fall into one of four queue types that we're working with,

252

which become buffers to put data into that might then be a stopping point off to its next stage of its existence.

253

So, you know, I think of queues very much like the phone.

254

If you have only so many operators that can answer the phone, but you have more people calling in, they may get put into a queue waiting to actually be processed.

255

And so from a technical perspective, if you're an application developer, this is what we often call decoupling.

256

You know, we have the generation of information, and we need to decouple it from the backend storage or use of that information.

257

We put it in the queue so it doesn't get lost, and then the backend can pull the information out of the queue.

258

But all of those data types are potentially available to store

259

in a storage account inside of a regionally based unit of replication.

260

Inside the blobs, they actually have several different types of blobs and the storage accounts themselves.

261

I'm going to say the vast majority of you are going

262

to be working with standard v2 generations of storage they provide

263

the most wide range capability of the type of data

264

that you can store inside of them and for use cases

265

and they're pretty good general use utility capabilities

266

if you need some high performance what we often refer to as ultra discs the speed

267

if you're familiar with terms called IOPS and throughput,

268

you're looking possibly at like 50 ,000 IOPS performed by your standard disk,

269

whether you're using standard HDDs or premium SSDs.

270

When you get into a premium block, you're getting things into ultra disks that will get you into 160 ,000 IOPS,

271

so significantly more throughput, but you're going to get less choices.

272

I'll again show this in the live demonstration when I get to the portal.

273

So these are going to be high performance requirements.

274

We have all those capabilities available for you.

275

They will also restrict the number and type of replications that are going to be available at the storage account.

276

I've already talked about the region pairs.

277

So here comes through, you know, taking a look at the region that you're dealing with.

278

I introduced the term of LRS or locally redundant storage.

279

If you need it copied over, you go to geo -redundant storage.

280

If you need to make it highly available with inside of a region, you can have zone redundant and we have geo zone redundant storage as well

281

so those become the different types and we have a version

282

that is going to make it read accessible or ra so

283

when i get to the demonstration you'll see

284

that i could make it read accessible geo zone redundant

285

that you're working with so that

286

if i have a geo redundant copy maybe i've got the read write copy in the primary zone

287

and that's where my changes are going to take place

288

but infrequently but let's say I have an application that is backlogged

289

and it can't get access in a timely manner from the primary region.

290

Potentially, you could write your application to get it from a read -accessible version in the region pair version you're dealing with.

291

Here are the different copies.

292

I've done all of this for you, so I'm going to go through this pretty quickly.

293

The LRS provides three copies and provides it in a synchronous connection inside of a single region.

294

ZRS provides three copies in a single region, but protects it.

295

Here again, those words, synchronous.

296

If you get into a multi -region, you have a primary region with GRS, and then you're going to have an async replication.

297

That delta time of approximately 15 minutes or no more.

298

to another region, and then you get into the read -accessible geo -redundant.

299

So it's very much like the geo -redundant, but what happens is you now have a read -accessible version.

300

So if you've got millions of users that are hitting your primary site and it's overrunning it,

301

potentially you could actually have it failover and potentially read that information from that other copy.

302

So instead of waiting in a long lineup to get to that one copy, you go, hey, there's another door I'd get over here, but that's up to your application developers to work with.

303

And they don't have the read -accessible geo -redundant storage that you're working with.

304

So there's GZRS, so geographic zone redundant, and then we get RAGZRS.

305

So those are the six different types of storage that you can work with throughout the Azure storage account, those different replications.

306

How you access a storage account is based on a URI that might be familiar to you.

307

Now, another eye -winking moment, you must remember this format.

308

So what you have is, starting from the right going to the left,

309

you've got a core .windows .com that is the same for all types of storage in the storage account.

310

Then you get the type of storage, whether it be a table, a queue, a blob.

311

And then you get the storage account name.

312

And it's because of this, it's maybe publicly accessible, your storage account names must be globally unique.

313

I'll do an example of this in the live demo.

314

I'm going to put the name of a very well -known company.

315

It's going to say, hey, that company, that name's already been used.

316

So it has to be globally unique.

317

And we've also added a recently new feature

318

that provides an appended value to the storage account name that makes it globally unique.

319

So if you come up with a name, but you do want to have a common naming structure.

320

Now, what you can do, we talked about DNS in a previous module you can use your DNS records to take

321

that really long name that may not make sense to anybody for the storage account name.

322

You could then convert that into the name that you actually want to use using my example of that company.

323

I could take this really long name

324

that doesn't make any sense to any of us

325

and I could then convert that into a simple name

326

that I could then make available to my developers and my users to access that information.

327

in a networking module we talked about this thing called service

328

endpoints where you could then connect a service like azure storage to a virtual network

329

and its subnets that you're working with

330

that sounds an awful lot like storage endpoints it's not a

331

storage endpoint is going to talk about how do i make my endpoint available

332

and some of the network configurations that i can put on it?

333

Do I want to make it publicly accessible or do I want to embed it only to specific subnets

334

inside of my Azure configuration?

335

What kind of routing do I want to work with?

336

So this is different than if you've watched that module on networking where we took a look at service endpoints.

337

These are just ways to secure the endpoint that people would use to connect to the storage account itself.

338

So let's go off and do a live demonstration, show you some of these features in action.

339

Okay, so what I want to do is walk you through the stages of actually setting up a storage account.

340

I'm not going to create it because I've got one already done, and then I'm going to go through the configuration of a storage account.

341

So the first step is, I don't know if I mentioned it during the presentation side, not all services are available in all regions.

342

It's kind of a general statement around Azure, and I'm going to demonstrate that some of the replication types

343

that we talked about in the presentation may not be available in all regions.

344

So I want to do that demonstration and then we'll take a quick pause

345

and then we're going to move over to a demonstration of the configuration of a storage account.

346

So to create a storage account, a lot of this has been seen in the other recordings where you have to have a subscription and a resource group.

347

Your storage account name has to be unique and you'll see this

348

when we come up in the creation of the storage account demo.

349

But I'm going to come to US West 3.

350

I'm going to compare this to Canada East in just a

351

We saw that there was characteristics of a standard versus premium account.

352

I'm going to focus on the standard here, where you can see all the different types of replication that we talked about in the lecture.

353

We saw that we have locally redundant, geo -redundant, zone -redundant, and geo -zone -redundant.

354

And this checkbox down at the bottom gives you the option to make the geo -zone and the geo -local -redundant storage.

355

read accessible.

356

So you can see that checkbox goes away for zone and local, but once I go to the geo options, it gives me the choice to make that georedundant read accessible.

357

Now I'm going to switch over to Canada Central, as I said.

358

Sorry, Canada East.

359

And you're going to see that not all those replication types are available.

360

You only get Local Redundant and Geo Redundant.

361

The two zonal options of Zone Redundant and Geo Zone Redundant are not available

362

because not all services are available in all regions yet.

363

It's coming to Eastern Canada.

364

It's in Central Canada.

365

So just make sure that you check those before you try

366

and deploy a resource type into a region that that resource type is available in that region.

367

So what you've seen is a storage of durable data that you might need to have offered through a storage account.

368

It's just one of the types.

369

We have other types for lightly structured things like Cosmos DB, Redis Cache, and we also have features like SQL that you can use in a variety of forms.

370

But for raw data that you're looking at,

371

whether it falls into that unstructured or lightly structured model in the traditional file shares or this modern method of blob storage,

372

storage accounts are the fundamental unit that you want to use is to configure to deploy storage.

373

Now with that as your background, there's gonna be a whole bunch of other configurations that we will cover, but in this one, we just needed to have you understand the basics of storage.

374

Thanks for joining us for this session.

375

To continue your learning, watch other videos in the course or explore more on Microsoft Learn at aka .ms forward slash learn.

アプリをダウンロード

流暢に話すために必要なすべて

AI発音採点文ごとに採点

IPA練習すべての音をマスター

単語学習自分の単語帳を作る

単語ゲーム遊びながら覚える

QRをスキャン

Download on theApp Store Get it onGoogle Play

同じチャンネル

FOR YOU

このレッスンの語彙とスピーキングのポイント

このスピーキングレッスンは、動画「Configure storage accounts」を教材にしています。繰り返し出てくる語は次のとおりです：storage, account, region, zone, redundant。この動画には、シャドーイング用の文が287文、単語が5125語あります。音声の長さは31:45です。話す速さは1分あたり約161語で、日常会話に近い自然なペースです。単語の82%は英語の頻出3,000語に含まれます。残りは練習の前に確認しておきましょう。

この動画の重要語彙

動画に出てくる覚えておきたい単語15語を、発音と意味つきで紹介します。

単語	発音	意味
redundant 形容詞	/ɹɪˈdʌn.dənt/	冗長
availability 名詞	/əˌveɪ.ləˈbɪl.ɪ.ti/	供給, 可用性
node 名詞	/noʊd/	結節
configuration 名詞	/kənˌfɪɡ.əˈɹeɪ̯.ʃən/	構成, 配置
module 名詞	/ˈmɑd͡ʒul/	モジュール
queue 名詞	/kju/	列, 待ち行列
resource 名詞	/ɹɪˈzɔːs/	資源, 資産
connect 動詞	/kəˈnɛkt/	繋げる
component 名詞	/kəmˈpoʊ.nənt/	部分
dive 動詞	/daɪv/	潜る
capability 名詞	/ˌkeɪ.pəˈbɪl.ɪ.ti/	能力
demonstration 名詞	/dɛmənˈstɹeɪʃən/	実証
disk 名詞	/dɪsk/	ディスク, 円盤
deploy 動詞	/dɪˈplɔɪ/	配置する
demo 名詞	/ˈdɛm.oʊ/	デモ

動画に出てくる句動詞

単語	意味
go down 動詞	降りる, 降下する
clean up 動詞	掃除する
come back 動詞	戻る, 帰る
fill up 動詞	満たす
go back 動詞	戻る, 帰る

繰り返し練習したい文

動画に出てくる短く完結した文です。日常会話でそのまま使えます。

It's our favorite, it gets everything first.
You don't get to pick a data center.
I'll show this in the live demo.
I've already talked about the region pairs.
What kind of routing do I wanna work with?

この動画の文法

話し手がよく使っている文型を、動画の実際の表現とともに紹介します。

文型	動画での表現
現在完了形 have/has + 過去分詞 — 過去の出来事が今も関係している	I've said · We've seen · we've also shown
受動態 be + 過去分詞 — 誰がするかより、何が起きるかに焦点を当てる	be identified · be replicated · are called

注意したい発音

話し手はgonna, you're, I'mなど、短縮形や弱形を198回使っています。聞こえたとおりの短い形で発音しましょう。

「sh」と「zh」の音: potentially /pəˈtɛnʃ(ə)li/, configuration /kənˌfɪɡ.əˈɹeɪ̯.ʃən/, demonstration /dɛmənˈstɹeɪʃən/, presentation /ˌpɹɛzn̩ˈteɪʃn̩/, exception /əkˈsɛpʃən/
長い単語（アクセントの位置に注意）: accessible /əkˈsɛs.ɪ.bəl/, availability /əˌveɪ.ləˈbɪl.ɪ.ti/, potentially /pəˈtɛnʃ(ə)li/, configuration /kənˌfɪɡ.əˈɹeɪ̯.ʃən/, capability /ˌkeɪ.pəˈbɪl.ɪ.ti/

日本語話者が苦手な音：

/r/ と /l/ の区別 — /l/ は舌先を歯茎につけ、/r/ はどこにもつけない: ultra /ˈʌltɹə/, protocol /ˈpɹoʊtəˌkɑl/, replicate /ˈɹɛplɪkeɪt/, replacement /ɹɪˈpleɪsmənt/, reveal /ɹɪˈviːl/
/v/ — /b/ にならないように、上の歯を下唇に当てる: availability /əˌveɪ.ləˈbɪl.ɪ.ti/, dive /daɪv/, provider /pɹəˈvaɪ.də(ɹ)/, developer /dɪˈvɛləpɚ/, convert /kənˈvɝt/
/f/ — 「フ」ではなく、上の歯と下唇で出す: configuration /kənˌfɪɡ.əˈɹeɪ̯.ʃən/, format /ˈfɔːɹ.mæt/, refer /ɹɪˈfɜː/, geographic /d͡ʒiəˈɡɹæfɪk/, awful /ˈɔːfʊl/

この動画での練習方法

まず声を出さずに動画を最後まで聞き、知らない単語をメモします。
まず0.75倍速で一文ずつシャドーイングし、慣れてきたら通常の速度に戻します。
自分の声を録音して元の音声と比べます。redundant, availability, nodeなどの単語に特に注意しましょう。

シャドーイングとは？英語上達に効果的な理由

シャドーイング（Shadowing）は、もともとプロの通訳者養成プログラムで開発された言語学習法で、多言語習得者として知られるDr. Alexander Arguelles によって広く普及されました。方法はシンプルですが非常に効果的：ネイティブスピーカーの英語を聞きながら、1〜2秒の遅延で声に出してすぐに繰り返す——まるで「影（shadow）」のように話者を追いかけます。文法ドリルや受動的なリスニングと異なり、シャドーイングは脳と口の筋肉が同時にリアルタイムで英語を処理・再現することを強制します。研究により、発音精度、抑揚、リズム、連音、リスニング力、そして会話の流暢さが大幅に向上することが確認されています。IELTSスピーキング対策や自然な英語コミュニケーションを目指す方に特におすすめです。

シャドーイングのやり方: ステップ別の完全ガイドを読む →

シャドーイング練習: Configure storage accounts | AZ-104 | Episode 16 - 動画で英語スピーキングを学ぶ

練習モードを選ぶ

アプリをダウンロード

同じチャンネル

Understand Microsoft Entra ID | AZ-104 | Episode 2

Course Preview | SC-100 | Microsoft Cybersecurity Architect

Course Introduction | AZ-104 | Episode 1

Course Preview | AZ-104 | Azure Administrator Associate

Course Preview | AI-103 | Develop AI apps and agents on Azure

おすすめ動画

Database vs Data Warehouse vs Data Lake | Explaining the Differences

Best NextJS Folder Structures | Beginner - Intermediate - Advanced

Armchair Architects: Resiliency in the Cloud – Core Patterns

How do microSD Cards Store 2 TB in such a TINY space?

What is Docker? Docker container concept explained || Docker Tutorial 1

Give Me 15 Minutes. I'll Teach You 80% of Obsidian

Free CCNA | VLANs (Part 2) | Day 17 | CCNA 200-301 Complete Course

Database Sharding! Designing Data-Intensive Applications chapter 6

Redis Crash Course - the What, Why and How to use Redis as your primary database

Updated Essential AI Skills For 2026

Can You Remember These English Sentences? | 3-Step Speaking Practice #listenandrepeat #shadowing