HackyViolette

人生暇つぶし

【TOEIC】金フレまぎらわしいシリーズ 3

76 introduce - 431 install:「導入する」の比較

  • introduce: 導入する、紹介する
  • install: 設置する、導入する、(プログラム等を)インストールする

英語「introduce」の意味・使い方・読み方 | Weblio英和辞書

英語「install」の意味・使い方・読み方 | Weblio英和辞書

導入するって英語でなんて言うの? - DMM英会話なんてuKnow?

フレーズ・例文 この夏、新しい商品ラインを売り出しました。|語学学習コミュニティ ゴガクル英語

"introduce" は「(商品などを)売り出す」「(外国のもの、方法等を)導入する」の意味。

"install" は「備え付ける」意味。

No.76 の "introduce" は「(商品などを)売り出す」の意味で覚えた方がよいかもしれない。

200 determine - N/A decide:「決定する」の比較

  • determine: 決定する、判断する、決心する

【英語】decide/determine(決める、決心する)の意味の違いと使い分け

decide: よく考えて決める

determine: 強い決意

determineとdecideの意味の違い | ネイティブと英語について話したこと

そもそも decide と determine は全く別の意味。

determine は「判断する」「解明する」の意味。

be determined to V で「〜することを決意する」の意味になる。

金フレの例文の場合、「社内でよく議論した末に決めた」ようなニュアンスを感じるので"decide" の方が意味が近そう。

244 related - 486 relevant

  • related: 関連した
  • relevant: 関連した

【relevant】 と 【related】 はどう違いますか? | HiNative

"related" はより一般的な関連を示し、"relevant" は事物に密接に結びついた関連を示す。

Since teamwork and productivity are closely related, he should analyze the relevant data.

406 notify - N/A notice

  • notify: 知らせる
  • notice: 気がつく 通知

"notice" は他動詞として「〜に気がつく」という意味。

425 renovate - 458 remodel

  • renovate: 改装する
  • remodel: 改築する、リフォームする

Remodeling Vs Renovating: Definitions | Sleeping Dog Properties, Inc.

"renovate" はアップデートや改修するイメージ、"remodel" は劇的に変更するイメージ(間取りや部屋のコンセプト等)。日本語訳の「改装する」と「改築する」のイメージの違いと同じ。

468 approximately - N/A about

"approximately" の方が堅い。

331 assure - 345 guarantee - 404 ensure

  • assure: 保証する、請け合う
  • guarantee: 保証する 保証
  • ensure: 保証する、請け合う

他にも綴りと意味が似た単語に "insure" がある。

以下のページがわかりやすい。

guarantee, warranty, assure, ensure, insure の違い | Nuancebook

assure: 人に何かを保証して安心させる。promiseに近い。

guarantee: 何かが起きる事を保証する。

ensure: 何かが起こることを確かにする。guaranteeよりはカジュアル。make sureと同義

insure: 金銭的に保証する。保険をかける(加入する)。

【TOEIC】金フレまぎらわしいシリーズ 2

前回記事はこちら

オフィス用品・機器

#10
new office equipment

#79
office supplies

jp.berlitz.com

  • office equipment
    • 耐久消費財(機器・用具)
    • 非可算名詞
  • office supplies
    • 消耗品等(紙・ペン・インクカートリッジ)
    • 他の名詞の前に来る場合(office supply store)等を除いて supplies の形

値引き

#356
significant savings

#NA
discount, sales

yoso-walk.net

  • savings は基本的には「(お客さんが)節約する」という意味。

www.mkikuchi-law.com

  • savings は契約書でよく利用される。

eow.alc.co.jp

  • savings と discount
    • 「値引」という意味では discount と同じ。
  • savings と sales
    • 調べてもあまり違いが出てこなかった。
    • sales は売上の意味でも使われるので、significant sales impact のような形で使われることが多い?

AWS独特の言い回し

本日 2022/4/21 の日経新聞(日刊)2面に載っていた以下の記事についてやいのやいのいいます。

www.nikkei.com

記事内容の揚げ足取り

気になったのは以下の文言

350項目ある要件には「独立したリージョンを複数のゾーンで構成」「HTTPのAPIが利用可能」などAWS独特の言い回しが並んでいたからだ。

「独立したリージョンを複数のゾーンで構成」はAWS/Azure/GCPといったパブリッククラウドでは共通した用語だし、「HTTPのAPIが利用可能」に関してはクラウド独自の言い回しでもないですよね。ツッコミどころ満載です。

と、ネタはここまで。

350項目の要件について

要件の原文を調べてみました。

下記ページの「別紙1」が要件ですかね。

www.digital.go.jp

要件を全部読んだわけではないですが、主要パブリッククラウドを念頭に置いたものであることがわかります。

今回「AWS独特の言い回し」とされていたのは以下の部分と思われます。

基本事項 No.8

DR考えれば当然ですね。

(5)API関連機能 No.1

新聞を読んだ限りだと、「公式としてCLISDKを介さずに素でHTTP叩くことをサポートしている」のが要件かと思い、「え?CLISDK使わないの???」と思いましたがどうやらそうではなさそうです。 ちゃんと HTTP "プロトコルベース" と書いてありますね。

ただ、No.2 を見ると 「REST API をマネージドサービス」として利用したいようなので、素でHTTPも叩きたいということですかね。 クラウドの知識がないのであまりわからないのですが、素でAPI叩くのって何かメリットがあったりするのでしょうか(CLISDKとかよりバージョンの管理が大変そう)。

最後に

記事(有料部分)では、AWS/GCPが有力、国産クラウドは戦えない的なことが書いてありました。そこについては全くもって賛成です(なんでAzureやOCIがダメなのかはわかんなかったけど)。 結局アメリカのパブリッククラウド構築・マイグレーションの案件で食っていくしかないのかなぁ。。悲

【TOEIC】金フレまぎらわしいシリーズ 1

金フレのフレーズを覚える中で、同義語や類義語で答えてしまうことがよくあります。金フレをまんべんなく全部覚えたいのでバッドノウハウではありますが情報を整理していきたいと思います。

ストックはまだまだあるのですが、今日調べた内容を記します。

Noが()になっているものは見出し語としては扱われていないということを示しています。

示す系

似ている単語
No Word JP
21 indicate 示す
421 imply ほのめかす、暗示する
意味の違い

imply は 「(暗に)ほのめかす」という意味がある。

見分け方

どちらも "What is i_____ about foobar?" という形のフレーズとなっているため間違いやすいが、和文に「ほのめかす」というワードが入っているため識別可能。

候補者

No Word JP
52 candidate 候補者
(19) applicant 応募者

applicant は応募書類を提出しただけの人、candidate はその中で候補として名前が上がっている人。場合によっては言い換え可能。

探す

No Word JP
217 seek 探し求める
238 search 捜索、検索
探す、検索する
意味の違い

ネットで調べると、seek は「形のないもの(方法とか)を探す」、search は「形のあるものを探す」という解説が多いが、信憑性に欠ける(おそらく100%完璧ではないがニュアンスとしてはそんな感じということだと思う)。

英語「seek」の意味・使い方・読み方 | Weblio英和辞書

  • seek の過去形・過去分詞形は sought
  • 自動詞としての用法もあり、「(他動詞よりも)執拗に探す」という意味。
見分け方

①the search for foobar

②seek foobar

のような形になっている。

「探す」の意味的にもほとんど同じように見えるため、例えば以下のような言い換えが可能だと思う。

①seek for foobar(動詞としたいのでtheを外す)

②search for foobar(search Aだと意味が変わってくるのでforを入れる)

金フレでは「他動詞のseekを覚える」ことを意識して見分ける。

【TOEIC】GW終わるまでに金フレを1000まで覚えます。

今日は金フレ1-400までを初見テストしました!

publications.asahi.com

学生時代(6〜7年前)に金フレ覚えただけで745点取れた実績があるので金フレには絶大なる信頼を寄せています!

まずは金フレを完璧にして学生時代くらいの英語力まで戻して、今年度中にTOEIC900を取りたいとなんとなく思ってます(900はそんなに甘くねーよという声が聞こえてきそうです)。

テストをやってみて、だいたい9割くらいはまだ覚えていますね。

昔はページを開いた瞬間に単語の順番とか、日本語を読んだ瞬間に英語のフレーズ全体が頭に浮かぶまでやり込んでいたのですが、そこまでは無理でした。

しばらくは単語をやりつつ、英語トレーニングの計画を立てたいと思います。武田塾の参考書ルートが欲しくてLINE登録したんですが、案内が一向に来ないです。こちらから希望しないといけないんですかね?(相談必須ならちょっと遠慮したいなぁ)

PodSpecとContainerフィールドでのSecurityContextの違い

CKAD試験勉強シリーズです。

SecurityContext は PodSpec(spec.securityContext)とContainer(spec.containers[*].securityContext)のどちらでも設定することができます。

基本的にはこれらはスコープが異なります。

spec:
  securityContext:       # Podスコープで適用される
    runAsUser: 1010
  containers:
  - name: hoge
    image: busybox
    securityContext:     # hogeで適用される(Podスコープより強い)
      runAsUser: 1011
  - name: fuga
    image: busybox
    # securityContextが設定されていないのでPodスコープのものが適用される

最初は単に Pod と Container のスコープの違いだけかと思っていましたが、どうやら指定できるフィールドが異なるようです。

PodSpecのSecurityContext

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core

ContainerのSecurityContext

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core

試験で出そうな範囲に絞ると以下の違いがあります。

フィールド PodSpec Container
runAsUser
runAsGroup
privileged
capabilities

権限周りはContainerのフィールドに入れないといけないようです。

spec:
  securityContext:                   # Podスコープで適用される
    runAsUser: 1010
    # ここではcapabilitiesは指定できない
  containers:
  - name: hoge
    image: busybox
    securityContext:
      capabilities:                  # capabilitiesはcontainersの中で指定
        add: ["SYS_TIME"]
  - name: fuga
    image: busybox

一旦ここまで。ありがとうございました。

StorageClass の Dynamic Provisioning と VolumeBindingMode について

CKA受験勉強時にはStorageClassについて全くと言っていいほど知らなかった(なんかあるなぁって感じ)のですが、CKAD受験に向けて基本のキを知ったのでメモします。

StorageClass

kubernetes.io

ストレージの実体をどのようにプロビジョニングするかの定義的なものと理解しました。

主なフィールドは以下の通りです。

  • provisioner: Volumeプラグイン(どのような形でストレージを実装するか)を指定
  • parameters: Volumeプラグインのパラメータを指定
  • reclaimPolicy: Delete / Retain(PVCの削除とともにPVを削除 / PVC削除後にPVが残る)
  • volumeBindingMode: Immediate / WaitForFirstConsumer(PVC作成後即PVを割り当てる / PodでPVCが使われるまでPVを割り当てない)

example-sc.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: example-sc                 # 本来はこのような名前はNG(容量重視とかパフォーマンス重視とかわかりやすい名前をつける)
provisioner: kubernetes.io/aws-ebs # AWS EBSプラグインを使用(PVの実体)
parameters:
  type: gp3                        # EBSのgp3を指定
reclaimPolicy: Retain              # PVC削除後もPVは残る(再利用できるわけではない)
allowVolumeExpansion: true
mountOptions:
  - debug
volumeBindingMode: Immediate       # PVC作成後すぐにPVが割り当てられる

PVやPVCマニフェストでもこのStorageClassが設定されています。

設定しない場合はデフォルトのStorageClassが当たります(デフォルトがあれば)。

example-pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv
  labels:
    type: local
spec:
  storageClassName: example-sc # StorageClassを指定
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"

example-pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: example-pvc
spec:
  storageClassName: example-sc # StorageClassを指定
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi

Dynamic Provisioning

PV を使うためには基本的には以下の流れでリソースを作成していきます。

  1. StorageClass 作成
  2. PV 作成 ※
  3. PVC 作成 ※
  4. Pod 作成(volumesに PVC を指定)

※ PV 作成と PVC 作成は実際にはどちらが先でもよいです。

このような流れで作成した場合、Podを作成するときには PV と PVC が先に存在しなければなりません。

PVC は StorageClassやAccessMode、Resources の要件に合う PV を探すので、この例の場合にはstorageClassName==example-sc, accessMode==ReadWriteOnce, requests.storage==3Gi(以上)を探し、example-pvとバインドされます。PVとしてEBSが10Gi確保され、PVCで3Giリクエストされている状態です。これはPVCに対して過剰な容量のPVが当たっているのでストレージが無駄になります。

それを解決するのが Dynamic Provisioning です。

kubernetes.io

Dynamic Provisioning では PVC が作成されたタイミングでその要件に沿った PV を作成しバインドします。そのため過剰なストレージ容量を食うことなく PV を作成することができます。ただし、Dynamic Provisioning に対応した provisioner を利用する必要があるため注意です(EKS / AKS / GKE を利用し、クラウドストレージを普通に利用する分には問題ないです)。

以下のように用途に合わせてslow, fast といった StorageClass を作成できます(GCP PDを利用する場合の例)。

example-sc-dynamic.yaml

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd

PVC を作成する際にこれらの StorageClass を指定することで、用途にあった PD タイプ(pd-standard or pd-ssd)で PV を確保できます。

VolumeBindingMode

VolumeBindingMode は PVC が作成されたあとにどのタイミングで PV とバインドするかをコントロールする仕組みです。

kubernetes.io

Immediate モードの場合には、PVC 作成後すぐに PV のバインディングとプロビジョニングが行われます。

WaitForFirstConsumer モードの場合には、PVC 作成後、Podが作成されるまではバインディングとプロビジョニングは行われません。

Dynamic Provisioning と VolumeBindingMode の関係

きちんと手元で検証したわけではないですが、以下のような動きになると思います。間違っていたらすみません。

Dynamic Provisioning VolumeBindingMode PVC 作成後の動作
Immediate 即時 PV が払い出されバインドされる。
WaitForFirstConsumer PV は払い出されない。
PVC を利用する Pod がスケジュールされるタイミングで PV が払い出されバインドされる。
Immediate PV は手動で作成する。
PVC と PV は条件が合うものが見つかり次第即時バインドされる。
WaitForFirstConsumer PV は手動で作成する。
PVC を利用する Pod がスケジュールされるタイミングで PV と PVC がバインドされる。

※手動というのはあくまでも「Dynamic Provisioning の機能を使わない」という意味です。

ローカルストレージの場合(no-provisioner)

ローカルボリュームの場合には Dynamic Provisioning はサポートされません。provisioner として no-provisioner を指定します。

example-sc-local.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

とりあえず今日はここまでにします。ありがとうございました。