  |
はてなキーワード: メンテナンスとは
ホルンの元増田さんが追記で「ディスったつもりはない」と仰っておりますので、この議論に関してはこれ以上反論も補足もいたしません。
ただ一点、元増田さんには「あのような書き方をすれば尺八（またはマイナーな民族楽器全般）がディスられたと感じる読み手が私を含め一定数居る」ということだけはご認識いただきたいです。
それより私が驚いたのは、はてなの中でどのようなきっかけであれ尺八という楽器にここまで注目していただいたということです。
特に「面白い」「勉強になった」「尺八吹いてみたくなった」等のコメントは予想外で本当に涙が出るほど嬉しく、励みになりました。
これが元増田さんへのツッコミという形ではなく単発のエントリだったとしたら、たとえ同じ内容でもここまで反響を頂けなかったと思うのです。
こんなチャンスはもう二度と来ないと思うので、今回の件をきっかけに尺八に興味を持っていただいた方に向けて、もう少し書かせてください。
尺八がマイナーな楽器であることは十分承知していますが、少しでも楽器としての魅力をお伝えしたく、なるべく専門用語を使わずお伝えさせていただきます。
流派によって多少の違いがありますが、基本的にカタカナで縦書きに表記されます。
基本となる音は5種類で、順に「ロ、ツ、レ、チ、ハ（リ）」となっています。
このカタカナは音程ではなく指使いを表しています。ギターでいうところのTAB譜に近い表記です。ですので同じ音程でも指使いが違えば表記も変わりますし、逆に表記が同じでも尺八の長さが変われば出てくる音の高さも変わります。
音の種類は替え指や特殊奏法を全部カウントするとおよそ30種類です。殆ど全ての音が西洋音楽の12音に対応していますが、中には五線譜では表現できない替え指や特殊奏法もあります。
尺八の音域はおよそ２オクターブ半ですが、ホルンと同じく音域の高い音は正確に当てるのが難しいです。
しかも、高い音の中にたった一つだけ、なんと足（正確には太もも）を使わないと演奏できない音が存在するのです！足を使わなくても音自体は鳴ることは鳴るのですが、ピッチが上ずってしまい使い物にならないのです。
指使いや首振りだけではこのピッチのずれをカバーしきれないので、太ももで尺八最下部の息の出る穴を塞いでしまい、首振りのくだりでご説明した「開口端補正」を利用してピッチを適正な所まで下げているのです！
繰り返しになりますが、基本の尺八は指孔が５個しかありません。これによる最大のデメリットは「細かいパッセージが吹けない」ということです。
基本の音だけで構成されたパッセージなら吹けなくもないですが、半音や特殊音が混じってくると、かなり厳しいです。そう考えると５孔で平然とジャズを吹きこなすZac Zinger氏はマジで化け物です。
このデメリットを克服するために、指孔を増やした尺八が存在します。まとめて「多孔尺八」と呼んでいますが、メジャーなものは６孔と７孔で、多いもので９孔があります。
指孔が増えることで、本来であれば「首振り」や「指孔を少しだけ開ける」などの細かい動作を必要とする音も指孔の開閉だけで出すことが可能になります。
この多孔尺八を「邪道だ」と毛嫌いする奏者もいますが、私はこれにより尺八音楽の表現の幅が広がるのであれば良いのではないかと考えます。
プロの定義が曖昧なので何とも言えませんが、メディアに複数回登場したり、CDを出したり、定期的にリサイタルを開催している奏者に限定すれば、国内で100～150人くらいではないでしょうか。
最近活躍している若手プロはその多くが東京藝大の尺八科邦楽科尺八専攻出身です。https://hougaku.geidai.ac.jp/
そんな中、メディアへの登場頻度が図抜けて高い現役プロ尺八奏者が２人存在します。一人は「和楽器の貴公子」こと藤原道山氏、もう一人は「美人すぎる尺八奏者」こと辻本好美氏です。
辻本好美氏の演奏は、実は某テレビ番組で毎週必ず、それも何回も使われています。正解は以下の動画の1:55あたりから。
https://www.youtube.com/watch?v=2NfBpCQ5VYQ
お二人とも人気実力ともに申し分ないですが、私が個人的に一番好きなプロ尺八奏者は小湊昭尚氏です。彼の演奏がきっかけで尺八の世界に興味を持ったと言っても過言ではありません。
小湊さんがYOASOBIの「夜に駆ける」を尺八でカバーした動画は超絶オススメなので是非皆さんにご覧いただきたいです。先ほど紹介した「足を使わないと出せない音」や「首振り」も速いパッセージの中でバンバン使っていて、言葉がありません。
https://www.youtube.com/watch?v=LI0nzOKtTuk
尺八と聞いて多くの方がイメージされる「ブヒョ〜」という荒々しい音ですが、あれは口腔内や唇の形状を変えることで敢えて乱気流を発生させ雑音を含ませていて、専門用語で「ムラ息」と呼んでいます。
やり方は奏者によって様々ですが、基本的には舌の先端を下の歯の付け根あたりに巻き込んで通常より強めの息で吹き込むことで鳴らすことができます。
このムラ息、曲中であまり多用しすぎるとうるさい演奏になってしまいますので、ベースは綺麗な音で演奏し、ここぞという時に使用しています。ちなみに上記紹介の「夜に駆ける」動画の中では3:06あたりで使用されています。
本当はもっともっとお伝えしたいことがあるのですが、長すぎると逆に興ざめになってしまいそうなのでここまでにします。
ここまで読んでくださった皆さん、本当にありがとうございました。
尺八に関する質問があればトラバやブコメにお寄せください！可能な限り追記で回答いたしますので。
2/26 追記
皆様ありがとうござます。これまでに頂いたブコメからいくつか回答いたします。
兎にも角にもまず楽器が無いと始まらないのですが、これには明確な回答がございます。
ズバリ、「プラスチック尺八 悠」の一択です。初心者用の尺八としてはこれ以外の選択肢は無いと言っていいでしょう。価格は約16,000円です（昔はもうちょっと安かったんだけどなぁ…）。
https://www.amazon.co.jp/dp/B00P2FXKRS/ref=cm_sw_em_r_mt_dp_VR20JYRNZ0YEQJ2QWS28
ヤフオクやメルカリなどで中古の竹製尺八が売られていますが、初心者には高確率で地雷となりますので絶対に手を出さないでください。実家の押入れに眠っていた尺八も避けた方が無難です。
理由として、竹製は太さがまちまちで本人の口に合わない場合があること、手入れがされておらず割れていたり調律されていない場合があること、作者がわからないのでクオリティが玉石混淆なこと、などが挙げられます。
その点「プラスチック尺八 悠」はその名の通りプラスチック製なので太さ、仕上がりが均一で、乾燥などによって割れる心配がなく、プロ尺八奏者による監修もされております。
もし竹製の尺八が欲しくなっても絶対に一人判断して買わず、信頼できる師匠、尺八奏者、製管師と一緒に選んでください。
尺八選びを間違えたために最初の段階でつまづき、「私には無理だ」「やっぱり尺八は難しい」と思い込んでリタイヤする人の何と多いことか。残念でなりません。
楽器以外に必要なのは譜面台、チューナー、露切り（管楽器でいうところのスワブ）、テキストくらいでしょうか。
譜面台は尺八用をお勧めします。蛇腹式で横に広がるので主に縦書きの尺八用楽譜を置くのに適しています。
https://www.amazon.co.jp/dp/B000WMCB94/ref=cm_sw_em_r_mt_dp_HKHG69Q886CJS94SFZAP
チューナーは一般的なものであれば何でも構いません。スマホのアプリでも大丈夫です。
露切りは購入すれば間違いないですが、自作で手ぬぐいやハンカチに紐とおもりを結びつけた物でも大丈夫です。
練習後に露切りで尺八内部に付着した水分を拭き取って終わりです。簡単ですね。これも尺八の魅力です。
不可能とは言いませんが、できれば信頼できる尺八奏者から直に教わってほしいですね。
オンラインレッスンを開講しているプロ奏者も何人かいらっしゃいます。レッスン料は講師によって千差万別です。
各流派の師範などの肩書を持った方もいらっしゃいますが、師範＝プロではないので注意して下さい。実際にその人の演奏を聴いたり体験レッスンを受けたうえで決めた方が良いでしょう。
最近はプロ奏者がYoutubeで解説してくれている動画もありますので参考になるかと思います。
https://www.youtube.com/channel/UCzD1bRWJ6o9ECnHRUVGctMw/videos
初心者用のテキストですが、個人的なオススメは「鳴るほどザ尺八」です。
https://www.amazon.co.jp/dp/4991014433/ref=cm_sw_em_r_mt_dp_Q2V39NSKQTAXAGBANXCG
著者の菅原久仁義氏は現役のトッププロ奏者で、多くの若手プロ奏者を育成した実績もお持ちです。
もしあなたが大学生であれば、「和楽器サークル」または「尺八サークル」に入会してください。懇切丁寧に教えてくれるはずです。
もし自分の通う大学にそうしたサークルが存在しない場合、近所の大学のサークルに相談するのも手です。
社会人になってから尺八に出会った私としては、同年代が集まって切磋琢磨できる環境と練習時間がある大学生が羨ましくて羨ましくて仕方ありません。
一緒に練習できる仲間って、本当にかけがえのない存在です。小中高の吹奏楽部での経験があるからこそ、尚更そう思います。
ホルンの知名度のくだりでも少し話題になりましたが、国内唯一の和楽器専門誌「邦楽ジャーナル」によれば、現在の尺八人口は国内におよそ2万人とのことです。
他の楽器の人口がわからないので、この数字が多いのか少ないのか、私には判断できません。詳しい方いらっしゃいましたら教えてください。
ご想像の通り、曲の調や音域に合わせて随時最適な尺八を選択しているからです。そのため、曲の中で転調があると動画のような持ち替えが発生します。
尺八は一寸刻みで長さの違うものがあり、一寸長くなると出る音が全体的に半音低くなります。
最も一般的な長さは一尺八寸（D管）で、次いで良く使われるのは一尺六寸（E管）、二尺三寸（A管）となります。
ちなみにこの「一尺八寸」が「尺八」という名の由来になっているといわれています（諸説あり）。
そうです。大甲のツです。
「夜に駆ける」動画では結構な頻度で使われていましたがこれは極めてレアケースで、通常の曲で使われることはほぼ無いのでご安心ください。
尺八が合奏用の「楽器」として使われ始めたのは明治時代以降で、それまでは禅宗の一派である普化宗の虚無僧が修行の一環として使う「法器」でした。
そのため、他の楽器と合奏することが禁じられていたのが原因と思われます。事実、虚無僧が吹いていた曲はそのほぼ全てが独奏曲となっております。
箏と三味線と尺八が合奏する曲がありますが、あの編成が成立したのも明治以降で、それ以前は胡弓という楽器が今の尺八のパートを担っておりました。
さらに、当時の尺八は現代の尺八とは違い管の内部が漆で整えられておらず細かい凹凸があったため、音程や音量が不安定でそもそも合奏に不向きだったことも原因かもしれません。
もういろいろがんじがらめで苦しくて死んじゃいそう。
といっても借金はないから、その時点で苦しさの程度は知れているか。
でも親の代で終わらすのがいろいろちょうど良すぎるんだよなぁ。
何を考えてこんな社員構成にしたのか。と言っても若者が新卒で入ってきてくれるような立派な会社ではないし、教育プログラムなんてものもないし、
経験あってなおかつうちに応募してくるような人ってなんか問題のある中高年ばっかりなんだよな。
初代社長のときから働いてた社員も知ってるけど、ああいう人たちの愛社精神と比べるといろいろな面でため息しか出ない。
すきま風も雨漏れもひどい。
その他、貸しているアパートも同様。
会社口座にお金はすこしあるけど、これを建て直したら間違いなく借金が必要なんだよな。
でも入れ替えないと仕事できないし、従業員の命が危険なレベルだよ。
ずーっと同じ仕事を同じようにやってるけど、10年以上前からこの業界が衰退することは目に見えてたよね。
でも新規事業はコストがかかるからってなにも始まらなかったね。
なんかこういう状況を見て、現社長(僕のパパ)批判に傾くのは安易すぎてダメなように感じるが、
一応黒字の会社なんだけどさぁ、初代が購入した不動産あっての黒字なんだよなぁ。
もう廃業して全部の建物取り壊してコインパーキングに貸し出した方が儲かる程度の利益なんだよね。
この10年間高くはない給料で全力で仕事してきたつもりだけど、
なんかもう自分のやってきた仕事が親の壮大な介護に思えて仕方がない。
親の優雅な老後生活のために一生懸命稼いでいるだけに感じてしまう。
まあそうは言っても、親は親で俺に会社なんて継がせずに土地を切り売りしていけば優雅な老後生活は送れるからね。
俺がもらってる面ももちろんあるんだけどね。
まあVMWorldとかで10年以上人生の春を謳歌してきたからもう十分やろ
お疲れさん
～VMwareが提案する、DRにも対応するマルチクラウドソリューション～
昨今のCOVID-19流行への対応やDXを推進する中で、クラウドサービスの利用はビジネススピードの加速や柔軟なシステム運用に効果的であり、従来のオンプレミス環境と併用するハイブリッド環境や、複数のクラウドを利用するマルチクラウド環境が増えている。一方で、これらの環境を維持していくには課題も多く、セキュリティリスクも増大してしまう。ここでは、こうした課題を解決するVMwareのソリューションを紹介する。
COVID-19流行への対応やDX（デジタルトランスフォーメーション）のためのビジネス変革が進む中で、ビジネススピードの向上やニーズに対する迅速で柔軟な対応がこれまでになく求められている。これらを実現するために、アプリケーションの変革やクラウドへの移行が加速している。
多くの企業が、「ビジネスのスピードに対応できるモダンアプリケーション」や、「あらゆるクラウド、データセンター、エッジでビルドおよび実行が可能であること」、「エンタープライズクラスのレジリエンス、セキュリティ、運用の実現とビジネス変革」がDXを実現するために必要であると考え、これらを実現するためにマルチクラウド環境の活用が前提になってきている。
具体的には、Amazon Web Services(AWS)、Microsoft Azure(Azure)、Google Cloud Platform(GCP)といった複数のパブリッククラウドサービスを併用し、適材適所で使い分けているのが現状であろう。しかし、マルチクラウド環境では解決が必要な課題が存在する。その課題とは、「ワークロードのシームレスな移行・連携」、「クラウドごとのスキル習得」、「運用管理の簡素化」、「セキュリティリスクの低減」、「最適なコスト管理」の5つである。この5つがクラウド利用の理想と現実のギャップとなっており、これらを意識して進めていく必要がある。
特にマルチクラウド環境を適材適所で使う場合、クラウドごとに利用する技術が異なるため、設定項目や内容に違いがあり、その設定ミスによるインシデントも発生している。重大な影響を及ぼす場合もあるため、それぞれのクラウドを扱う際のスキルが重要になる。
こうしたマルチクラウド環境における課題を解決するには、一貫性のあるクラウドインフラストラクチャ、および運用管理サービスが重要なポイントとなる。例えばVMwareは、複数のパブリッククラウドだけでなくオンプレミスを含むハイブリッドクラウド環境においても、仮想的なレイヤーを構築することで管理や運用を一元化している。
VMware Cloud on AWSは、VMwareとAWSが共同で開発したもので、AWSのベアメタルサーバー上にvSphere、NSX、vSAN、vCenterを導入し、ホスト専有型のクラウドサービスとして提供するものだ。
その特長は3つある。1点目は「VMware製品をベースとしたクラウド」であること。VMware製品で仮想化されているため、AWSの世界にいながらオンプレミス環境で利用していたスキルセットや運用管理ツールを利用でき、新たなスキルを習得する必要がない。
2点目は「シームレスにクラウドに移行できる」こと。ワークロードをオンプレミス環境から無停止で移行することができる。アプリケーションを更改する必要もないため、クラウドに移行する時間やコスト、リスクを大幅に削減することが可能だ。
3点目は「VMwareが管理を行う」こと。ハードウェアやソフトウェアのトラブル対応や運用管理、メンテナンス対応など、すべてサービスの中でVMwareが実施する。3カ月に一回の頻度で新しいリリースを提供しており、ユーザーの要件を反映しながら新たな機能を追加している。
最近のアップデートの大きなものとして、日本で第2のリージョンとなる大阪リージョンを設置し、サービス提供を開始したことが挙げられる。例えば西日本地区でデータセンターを持つユーザーは、より低遅延でサービスを利用できるようになった。昨今は感染症の流行や地震の発生などによってBCPを見直すユーザーが増え、VMware Cloud on AWSをリカバリサイトとして利用するケースも増えている。その意味でも、大阪リージョンは活用度が高いといえる。
VMware Cloud on AWSが選ばれる理由は、大きく3つ挙げられる。1点目が既存のノウハウや運用管理手法をそのまま踏襲できるという点。VMware製品をベースとしたクラウドサービスであるため、オンプレミス環境における管理者のスキルや運用ノウハウなど、既存の資産をそのままクラウド上でも活用でき、新たなスキルの習得や、運用管理手法の大きな変更の必要もない。クラウドとオンプレミス環境をvCenterから一元管理できる。
2点目が、規模に依存しないシンプルなクラウド移行を実現できる点。ワークロードをそのままクラウドへ簡単に移行することが可能だ。VMware Cloud on AWSには標準でVMware HCXが含まれ、これはオンプレミスのデータセンターとクラウド間のネットワークをL2延伸する。ネットワークがつながった環境で仮想化環境、VMをそのままマイグレーションできる。アプリケーションやIPアドレスを変更することなく、無停止でワークロードを移行することができる。
3点目が、モダナイゼーションを推進して、ユーザーのDXの加速を支援できる点。まず、クラウドならではのインフラストラクチャとして、1顧客あたり最小2ホストから最大640ホストまで拡張できるが、俊敏性を兼ね備えて提供される。例えば、ホストの展開に1時間半程度、ホスト数を追加するのに15分程度と、オンプレミス環境ではありえないスピード感で環境を構築、提供される。
また、リソースを最適化する機能も提供される。ユーザーのリソースの使用状況に応じて、利用するホストの台数を自動的に増減させて最適化する。さらに、名前の通りにAWSが提供する各種サービスとの親和性が非常に高いことも特長。VMware Cloud ENIと呼ばれる専用のインタフェースを経由して接続することで、低遅延で高速な環境を利用して各種のAWSのサービスとシームレスに連携することができる。この面も同サービスの大きな強みとなっている。
最近では、VMwareが提供するKubernetesディストリビューションであるVMware TanzuをVMware Cloud on AWS上で稼働させることが可能になった。これにより、短時間でコンテナ、Kubernetes環境が導入できるようになる一方で、ハードウェア、ソフトウェアの管理はすべてVMwareが行うため、管理者はKubernetes環境に集中できる。
VMware Cloud on AWSのユースケースには、主に「オンプレミス環境のクラウド移行」、「データセンターの拡張」、「災害対策サイト」、「次世代アプリケーションのプラットフォーム」の4つが多い。特に最近は、災害対策としての利用が増えているという。VMware Cloud on AWSをリカバリサイトとして活用する際に強力なサービスとなるのがVMware Cloud Disaster Recoveryだ。
VMware Cloud Disaster Recoveryを利用すると、平常時には本番サイトのデータをクラウド上のストレージ領域にレプリケーションしておき、万一DRイベントが発生した際に初めてVMware Cloud on AWS上にホストを展開し、保護していた仮想化環境をフェイルオーバーする。リカバリサイトとしてあらかじめ物理的なサイトを構築しておく必要がないため、大規模な初期投資が不要となる。
VMware Cloud Disaster Recoveryの特長
このタイプはオンデマンド展開型と呼ばれ、DRイベント時にホストを展開したタイミングでリカバリサイトに対する課金が開始される。復旧後に仮想化環境を本番サイトに戻すことで、ワークロードもフェイルバックでき、不要となったリカバリサイトのリソースも削除され課金も停止される。なお、オンデマンド展開型のほかに、事前にホストを展開しておく事前展開型も用意されており、RTOを重視する場合には事前展開型が推奨される
また同サービスは、最近話題になっているランサムウェアへの対策にも有効だ。クラウドストレージ上に本番環境のデータをバックアップする際には、リカバリポイントを長期的に保持することが可能である。このため、ランサムウェア攻撃に遭ってしまった場合、その直前の時点からリストアすることが可能となる。
マルチクラウド環境を可視化するVMware vRealize Cloud
マルチクラウド環境では、各クラウドが複雑化し、サイロ化してしまう可能性がある。クラウドごとに管理ツールや必要とされるスキル、ノウハウも異なるため、利用するクラウドが増えるほど複雑化、サイロ化の問題が大きくなり、その結果セキュリティリスクやコストが増加してしまう。そこで有効な解決策となるのが、クラウド環境をまたがって一貫性のある運用・管理を実現できるVMware vRealize Cloudである。
まず、VMware vRealize Operations Cloudは、VMware Cloud on AWSのリソースだけでなく、他のパブリッククラウド上のリソースも一元管理できる。複数クラウドの環境にまたがってデータを収集、分析評価を行うことで、例えば常にパワーオフ状態の仮想化環境や、実体がない状態のディスクなどを検知された場合に最適化していくことが可能。これにより、最終的にコストの最適化も図ることができる。
コストや運用を最適化できるVMware vRealize Cloud
また、VMware vRealize Log Insight Cloudによって、複数のクラウドを横断してログを管理できる。例えば、監視対象のイベント通知をあらかじめ定義しておくことで、不正な行動を検知した際には管理者に通知し、適切な調査と対応を行うことができる。セキュリティやコンプライアンスの強化にも有効だ。
さらに、クラウド間のネットワークの可視化は、VMware vRealize Network Insight Cloudで実現できる。End to Endを含むネットワーク全体を可視化できるため、ネットワークに関するトラブルシューティングや、不審な通信を洗い出すこともできる。また、アプリケーションの通信も把握できるため、アプリケーションの移行計画にも活用できる。
今後、DXの推進を加速していく上で、必ずしもひとつの環境、ひとつのクラウドを利用するのではなく、マルチクラウド環境の利用が当たり前になっていくと考えられる。そこで直面する前述の5つの課題に対し、VMware Cloud on AWSそしてVMware vRealize Cloudの活用は課題を解決するだけでなく将来への有効な投資となる。企業規模や業種に関係なく検討すべきソリューションといえるだろう。
はっきり言って、日本以外でRPAって全然流行ってないよ。理由として
・メンテナスをする者のスキルアップ、モチベーションに繋がらない
・自動化したところで、人が行う作業が減るだけで、そこからデータなどのインサイトが得られない
というのが主なんだけど、じゃあ海外だとどうやっているかと言うと、
・基本的にはUIを使って操作するのではなく、APIを使って操作する。
・よって、APIを有していない社内ツール等はなるべく導入しない
・社内で内製しているツールなどもAPIを開発する(今だとフロントとバックエンドは分離しているのが多いのでそのまま利用する)
として、極力一度作った物のメンテナンスを減らしている。(結局メンテナンスは必要だが)ただ、日本では経営者がITに弱いことが多いので、一見コストが減らせるように見えるRPAを選択してしまう。
物流と書かれているので、WEBアプリではなくWindowsアプリみたいのをポチポチしないといけないケースも多々あるかと思うしアプリがニッチ過ぎて、APIなんて付く見込み無いとかあるだろうけど、一人でやるのは心が壊れるのでRPAやるにしても、専任チームつくったり、派遣とかを雇ってチームで回すようにしてったほうが良いと思いますぞ。
中途で入社した会社で使用しているとある機械がある。よくエラーが発生し止まる。
業者を呼んだ方がいいのでは？と提案するも上司は毎回「この子今日ご機嫌悪いのよ」と取り合ってくれない。
だましだましで使っているこの状況が嫌で嫌でたまらなかったので、勝手に業者を呼んでメンテナンスしてもらった。
動力部のコイルや、回路がやられていて奇跡的にたまに動いていたそうだ。
長年放置していたので無料とはいかず（そりゃそうだ）、10万円程かかった。
それにブチ切れたのが上司。
とつめられてしまったが、満場一致で社内の皆は自分に味方してくれた。
人生で出会った中で1番ヤバい人だなと思っていたが、事情を聞くとこちらがそちらに合わせて上手くやっていくしかないなと感じた。
多様性に直面しているが、正直辞めたい。
『外見』
ほうれい線とマリオネットラインが日に日に存在感を増してくる。
笑うと目尻にしわ。ファンデーションがシワに溜まるってこういうことかと実感。
このまま時の流れに身を任せるべきなのか。
頬を糸で吊ってHIFFして、さらに月日をかけてそれをメンテナンスするべきなのか。自己満足のためだけに。
『仕事』
新卒で入社し、あれからあれから十数年。10年程ブラックとは言えないまでもグレー企業で働いた後、転職して今はまずまずホワイトでそこそこの給料をもらえている。管理職などにはなりたくない。できれば現状を維持したい。一兵隊として、そこそこでやっていきたいが、キャリアアップ！セルフディベロップメント！の圧よ。そんなガツガツしたくねぇ、けど生き残りてぇ。これまた中途半端。
『資産』
持ち家も子供もペットもいないので身軽。おかげさまで現金の貯蓄は結構あるのだが、資産運用とかするのは怖い。でもインフレに怯えている。こちらも中途半端。
『家族』
結婚して5年を超えて、パートナーに不満がないのは幸運だと思う。
子どもがいない夫婦してうまくやっているので、波風を立たせたくない。
子どもを設けるなら本当にギリギリのラインだが、ここまで欲しいと思ったことがないのでそういう人生だったのだろう。
親は今のところ健康だが、これからだろうな。ここが現状一番の不確定ポイントかもしれん。
『趣味』
いくつかの趣味を数年おきにハマる、冷めるを繰り返している。そのため何においても永遠の初心者。
何かに熱中できなくなったらこの先の人生相当虚無だろうなとは思っている。
結局何か大きな変化を起こしたいと思うほど困っていることはなくって、ただこれまでと同じ人生をあと30年とか続けていくのか、維持できるのかっていう気持ちと経済の不安なんだよなぁ。
こういうこと書くと、「はっきり断らないお前が悪い」と言われそうだけど、一昨日きた訪問営業が鬱陶しい。
以下、一字一句あってるわけじゃないけど、どういう会話をしたかをいくつか書いていく。
自分が住んでいる家は単身世帯専用の1Kの賃貸マンション。一昨日の金曜日の夜に仕事から帰ってきて晩御飯を食べ終わったときに、インターホンが鳴った。電話でもそうだけど、予定がない訪問の場合、自分は相手がなんと言っているのかうまく聞き取れないことが多く、この時もそうだった。一度聞き返すと、はっきりとはまた聞き取れなかったのだけど、水道がどうのこうので一軒ずつ回っているとのこと。もう一度聞き返そうかと思ったのだけど、「水道の点検か？ そんな話あったっけ？ こんな時間に」と疑問に感じながらも、もう一度聞き返すのも忍びないので、オートロックのドアを開けた。
部屋にやってきてドアをあけると、そこには20代半ばの青年(後から23歳と分かった)。「先日ポストに訪問案内を入れましたけど、見られましたか？」と青年。自分は基本、ポストに入っているチラシなどは目を通すようにしているのだけど、全く見覚えがなかった。
「台所の蛇口を見させてください」と言われたので、入ってもらったら、「普段、水道水って飲まれますか？」と聞かれたので、「飲みます」と返答(何なら、水筒に水道水をいれて会社にもっていってる)。その後、蛇口のキャップを外されて、浄水器をつけられた。
そして、「コップを貸してもらえませんか？」と言われたのでコップを渡し、普通の水道水と謎の薬をいれると、ピンク色になった。そして、青年は一言。「こんなに色が変わるんですよ？ こんなこと知って飲めますか？」。いや、これがどういう仕組みで変色してるか知らんし。「安全なら問題ないんじゃないですか」と返した。
その後、浄水した水と薬をいれると、何も色が変わらなかった。蛇口にはめる浄水器でもこんな違うもんなのだなとちょっと驚いた(仕組み自体よく分かってないのだけど)。
ただ、これは高い価格で売り付けてくる訪問販売じゃないかとみがまえていたら、1年間無料のレンタルをやっていて、その後に必要なくなったらやめてもいいとのこと。会社としてはその後、一定の割合で続けてもらえるのでそれだけで利益になるとのことだ。
それなら悪くないなと思って申し込んだ。書類に、クレジットカードや銀行の情報が必要ならやめようとかと思ってたけど、そういう記入もなし。
ただ、会社名と所属年数を書く必要があったのがよく分からなかった。自分は、1年前に所属していた部署が会社として別れ(子会社化)、転籍した形となったので、所属年数を1年と書くと、そこでやけにつっかかれた。親会社に所属していたなら、その期間も含めた年数を書いていいとのこと。親会社にもいた期間でいいって何だよ意味分からんと思って、「1年じゃダメな理由はあるんですか？」と聞いたら、「審査にとおらない可能性がある」とのこと。浄水器のレンタルに審査なんてものがあるのかと思いながら、そういうもんなのかと思ってとりあえず親会社にも所属していた期間に変更。
ただ、翌日(土曜日)、何かをもってくるとのことで、また訪問してくるとのこと。面倒くさいなと思いながら、しぶしぶ許可した。そして、青年が帰ってからさっきの水道水がピンクになる現象に調べようとGoogleで「水道水 ピンク色に変わる」と検索したら、1発目に「悪質な訪問販売にご注意を！」というページがヒット。内容としては、水質検査を偽って水道水に含まれる塩素で色が変わる薬をいれ、これは飲まないほうがいいから浄水器をつけたほうがいいと売り付ける商法らしい。自分の場合、無料レンタルだけどやっぱこれ悪質なやつなのかなと思った。明日また訪ねてくるみたいだし、その時にきっぱりと断って返却しようと思った。
翌日、訪ねてきた青年にまず、「昨日の水道水がピンク色に変わる現象調べたら、最初に悪質販売についてのページがヒットしたんですね。そこには色が変わるのはむしろ安心して飲むことができる証拠と書かれてあって」と言うと、「水道水を飲んじゃいけないなんて言ってないですよ」と青年。不安を煽るような言い方はしてなかったっけと思いながら、「水道の検査で回ってると言ってたと思うんですけど」と伝えると、「いや、検査なんて言ってないですよ。水道水の浄水器の説明で回っていると伝えました」と青年。ここは自分の勘違いだったよう。「そうやって怪しがられることってよくあるんですけど、こちらはいいものを提供しているので安心してください」と青年。これ以上、言い返す言葉も思いつかないし、今のところお金をとられるわけでもないので、とりあえず納得することにした。ちなみに持ってきたのは「メンテナンス保証書」というものだった。
これで終わりかと思ったら、「会社についての説明をさせていただきたいので、明日時間ありますか？」と青年。「それって聞く必要ありますか？」と聞くと、「はい。老後にむけたお金についての話もあるので、聞かれたみなさん勉強になったと好評なんです」と青年。面倒くさいけど、1年無料レンタルしてもらえるし、暇だしいいかと思って承諾。
で、今日(日曜日)、青年が訪れた。老後のお金の話と言うとiDeCoとかの話かなと思ったら、違うどころか青年はなんとiDeCoを知らなかった。おいおい、お金の話をするぐらいならそれぐらい知っておいてくれ。
そうして話し出したのは、老後のことを考えると賃貸より持ち家のほうがいいという話。賃貸だと老後も家賃を払いつづけなきゃいけないから、賃貸のほうがいいということを延々と聞かされた。一応、「持ち家だったら地震があったときに心配だし」と言うと、「それは、修繕積立金があるので大丈夫です」と青年。何が大丈夫なんだと思いながら、「持ち家だと住み替えしにくい」と言うと「売ったり貸したりしたらいいんです」と青年。「そんな簡単に売ったり貸したりできないでしょ」と言うと、「そういう物件はそもそもローン審査にとおらないので大丈夫です」と青年。だから何が大丈夫なんだと思っているとしまいには、「増田さんの懸念が全部解消されたとしたら、持ち家のほうがいいと思いませんか？」という謎理論。そりゃあ、懸念が全部解消されたらいいに決まってるだろと(なんなら、「懸念が全部解消されたとしたら、賃貸のほうがいいともいえる」)。
こちらも何か言い訳つけて断ろうと思ったのだけど、無理だった。
しぶしぶ、毎月の住宅ローンの返却が今の家賃とさほど変わらずに(月6万円)、通勤時間も変わらずに、住宅ローン控除がうけられる面積以上の家ならいいと伝えた。あるとは思わないけど、探すとのこと。
そして、いい家が見つかったら11日に見学に行く話になり、見つかったかどうかを伝えるために、明後日の火曜日にまた訪問するとのこと。
いやいや、意味分からない。電話でいいだろと伝えると、「そういうことを話すのは対面でやるのが重要なんで」と青年。ちなみに、訪問してから帰るまでに2時間が経過していた(途中、20分ぐらい私用で電話がかかってきたので、玄関に放置したまま離れてはいたけど)。
ちなみに、自分専用の会社のメールアドレスはもってないらしい(名刺に書いてないからうすうすそうじゃないかと思ってたけど)。
ところで、初日の金曜日、近くでずっと「好きな映画なんですか？」「好きなアニメは？」「好きなゲームは？」と矢継ぎ早に近い場所で話されて、コロナ禍なのだからもう少し配慮しろと思ったのだけど、今日、コロナについて話してビックリした。
ワクチンはうってないという。コロナにかかったらかかったでただの風邪なので、それはそれで免疫ができるのでいいという考えだそうだ。
「コロナ禍なんで、こうやって近くで対面販売するのはやめたほうがいいんじゃないですか？」と聞くと、「消毒して免疫つけてるので大丈夫ですよ」と青年。いや、そういう問題じゃないだろと。
「ワクチンぐらい打ちませんか？」と言うと、「ワクチンなんて怖いじゃないですか。5年後とか自分の体にどういう影響があるか。自分の知り合いにもワクチンを打ったことで目が見えにくくなった人がいて本当に危険ですよ。
自分の家族は誰も打ってないです。それに僕、B型肝炎になったことがあって肝臓が弱いんです」とのこと。社員もワクチン打ってない人が多いらしい。
こんな人が実在したのかと驚いた。
会社の事業の話も聞けば聞くほどうさんくさい。「最近は婚活の支援事業も始めて、後、芸能関係の仕事もやってたり」と青年。そんなこと、会社のWebサイトには書いてなかったぞと思ったし、怪しいとしか思えなかった(不動産やリフォーム事業についても書いてないけど)。
なお、こちらが嫌がっているオーラをだしていると、青年から「増田さん、僕のこと苦手ですか？」と聞かれたので、「正直、苦手です」と答えておいた。
さっき、持ち家についてのデメリットについて調べてみたけど、移動がしにくいということや災害についてぐらいしか見つからず、本当に青年のいうことが本当なら悪くない話ではないと思ってしまったのだけど、はたして、どうすればいいものか…。
とりあえず、持ち家をもつメリットは分かったし悪くないかもけど、御社は信頼できないので良い家があったら他の不動産会社経由で購入するとでも伝えようかなと思う。
よくよく考えると、これはワクチン拒否している人を一人減らすチャンスじゃないかと思って、「こんなコロナ禍ですし、ワクチン打ってくれるなら一緒にいってもいいですよ」って言ったけど、ダメだった。絶対にワクチンは打ちたくないらしい。打つとしてももっと今より安全なワクチンがでてからにするとか。そもそも、一度コロナにかかってるからワクチン打たなくても免疫あるとのこと。
後、ワクチンは日本の人口を減らすために使われているとか、ワクチンの会社でもトップの人は打ってないとか言ってた。
とりあえず、「陰謀論かよ」と突っ込んでおいた。
「じゃあ、ワクチンを打ってない同僚ならいいんですね？」とも言われたけど、「そもそもまだ御社を信じてないんですよ。だけど、ワクチンを拒否している人がワクチン打ってくれたら、ちょっとは信用していいかなってなるじゃないですか。それが、他の人に変わったら、逃げたなって思って、さらに信頼度落とします」と言って断った。
自宅充電という視点が抜けてる。自宅充電(普通充電)は家にあるコンセントからの充電で、急速充電じゃないから時間はかかる。家に車を停めてる間にゆっくり充電して翌朝には満タンになる、という電気自動車で一番使われる運用方法になる。
この記事によると、電気代は1kwhあたり30円、60kwのリーフe+なら1800円でフル充電できる。
https://selectra.jp/energy/guides/ryokin/1kwh
ガソリン車の燃費はリッター20kmだとすると、20km走るのに170円、1km8.5円かかる。リーフの電費はへいきんすると1kwhあたり7km、1kmあたり4円ちょっととガソリン車の半額で運用できるようになる。
さらにEVだとエンジンもトランスミッションも無いから、オイル交換も必要ないし各種メンテナンスコストも低くなる。
EVの方が圧倒的に安く運用できる。これが否定しようのない事実なんだよ。だから欧州や中国はものすごい勢いで電動化してるし、物流企業の配送車もEVに置き換わっている。
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
何だかんだで世の中には小泉構文で答えたくなる場面が沢山あるよね
歯科医院への定期メンテナンスに行けないのは定期メンテナンスに行くだけの経済的余裕時間的余裕が無いからです
けして定期メンテナンスの重要性を知らないからでも虫歯になっても安く直せるとたかを括っているからでもありません、って。
日本国民の歯の状況の悪さについて語られる際、
日本は保険制度があるので虫歯になってからの歯科医療の治療費が安く済むから虫歯になってもいいと思っていてメンテナンスを怠っている、
……という前提で語られる事が多いけれど
これって全然違うと思うんだよな
だってどんなに費用が安かったとしても、歯医者に行って削られるのって嫌じゃん。虫歯にならずに済むならそれに越した事はないに決まってるじゃん
なのにどうして「治療費が安いから虫歯になっても大丈夫だと判断して定期メンテナンスに行かないに違いない」などという誤解が生まれるんだろう
そうじゃないだろ、庶民はその定期メンテナンスの費用が高くて「払えない」から「行けない」んだよ。「行けない」のであって「行かない」ではない。
3千円のクリーニング代が払えなくて、その結果10万円の根管治療や50万円のインプラントが必要になってしまうんだよ。
挙げ句の果てに保険制度を廃止してアメリカみたいに全部自費にしようなんて話まで出てくる。そんな事をしたらどう考えてもますます悪化するのに。
歯科医院での定期メンテナンスに行く人を増やしたいなら、自己負担を下げる事と労働基準法を改正して傷病休暇を義務付ける事の方がどう考えても効果的なのに、
「行きたくても行けない」人が、「行こうと思えば行ける」状態にする事が何よりも大事なのに
患者が知識が足りなくて定期メンテナンスの重要性を知らずに自分の意思で行かない事を選んでいると決めつけて、患者への啓蒙ばかりに必死になっている愚かしさ。
妊娠中絶の話題で、10万円の中絶費用が払えなくて1億円の子育て費用を払う事になるとかいう話なんかでもそうだけど、
庶民が目先のお金を「払えない」んじゃなくて、「払えるけれど惜しんでいる」という前提で語る人達が多すぎないか
実際にはそうじゃなくて、ガチで余裕がなくて「払えない」んだよ。
医者とか政治システムを作ってる政治家や官僚だのは基本的に裕福な人間揃いなんだろうから
OSM は成功したボランタリー地理情報 VGI(Volunteered Geographic Information) の一例と説明されますが、あくまでそれは一つの要素であって、世の中に定着した「最大」の理由はボランティア運営によるクラウドソーシング手法を採用したことではありません
Google Maps のように商用利用時に制限のかかったウェブ地図よりも、より自由で、ある意味何でもできる OSM を採用する企業が増えたことで、OSM の認知度が向上するとともに、企業が OSM を用いたサービスで収益を生むことによる「エコシステム」がまわった。商用利用を許容することで民間企業による OSM のデータ更新と利用価値を更に高める正のフィードバックへとつながったのだと筆者は考えます。
https://medium.com/furuhashilab/show-the-niantic-flag-4ab03ed1c3ea
OpenStreetMapとは、自由に改変ができその利用もGoogleMapより自由度が高いことで有名な地図ソフトです。登山マップやゲームのマップなど、様々な分野で活躍しています。これの特徴は、無償のボランティアや利用する企業によるメンテナンスにあります。その中にはAppleやFacebookといったあまり地図に関係しないような企業も参加しています。
存在しない島を追加したり海岸をまっすぐにいじったりすることは可能ですが、当然そのようなこのはしてはいけません。地図としてきちんと整備することが第一で、OSMやその利用者の利益に繋がります。
ここで名指しで取り上げられているNianticは、ご存じのようにポケモンGoを開発運営する企業。
ポケモンGOの地図はOSMを元に作られています。ポケモンGOは日本だけでなく世界中で広く利用されており、その人口も非常に多いことで有名です。当然Nianticは世界でも指折りのOSMユーザーでありその恩恵を受けていますが、実はNianticはそのOSMに対する貢献が殆ど無いことでも有名です。
自身のアプリ内で直に使用し多くのユーザーの目に触れているものを、自らメンテナンスして貢献していないという実態はコミュニティの中に筒抜けです。
言ってみればNianticはみんなで作る地図にただ乗りしているわけです。
それだけなら大したことではないかもしれません。OSSを幅広く利用していても、その改善に努めないことが間違っては居ません。
ただ、Nianticの作っているポケモンGOはOSM自体への改ざんに繋がっているのが厄介な点です。ポケモンGoはOSM上の公園などの特定の場所にポケモンが出没しやすい仕様です。逆に言えばOSMをいじって自分の周囲に大量をポケモンを出してしまうことも原理的には可能です。そしてそのような改ざんがOSMのコミュニティの中で非常に問題視されました。現在は過去ほど大規模な改ざんは行われていないようですが、小規模な改ざんは今も続いているでしょう。当然、OSMは全世界的にそれが反映されるので、OSMを利用する企業や個人がその改ざんの被害者となり得ます。
それを知っているNianticは問題を放置し、修復を他の企業やボランティアに任せっきりにしています。ただ乗りを明らかに超えていることでしょう。
さらに、現在ではOSMを超えてGoogleStreetMapの改ざんも多く報告されています。実在しないものを審査させるために、その根拠となりうるストビューに意図的な改ざんをして審査を通すやり方です。
ここまでしてまでポケストが欲しい人が多いのが実情
また、ポケモンGoのポケストはそもそもIngressというゲームのポータルに由来します。最初こそこのポータルを設置する機能はポケモンGoにはありませんでしたが、現在はポケモンGoのユーザーでも申請や審査が可能となっています。しかし当然由来と使い方が違う物を別々のユーザーが申請・審査することは非常に軋轢を生むことになります。
現実問題、ポケモンGoで申請・審査ができるようになってからの不正なWayspotの登録は加速度的に広がりました。何も無いはず場所に大量のスポットが出現したり、本来はありえないものが登録されていたり。酷いときには地域毎で談合を行っています。さらにNiaticはあろうことかFourSquarer上から任意のスポットを抽出してスポット化しました。ユーザーに何も伝えずです。
これがポケモンGoの為だけならまだギリギリわかりますが、他のIngressや魔法同盟、ピクミンなどにも影響が及ぶスポットをこのような乱雑なやり方で作成することは問題です。
将来のゲームユーザーも使う物をポケモンGoの恣意的且つ数の暴力で歪めているのが現状です。
唯一のいいところですが、OSMのマッパーが少しだけ増えたことでしょうか。
→Z
・歌って踊れる
→SD
・歌で世界を救う
・時間を越えて過去の自分を倒した結果タイムパラドックスで消滅する
→武者
・その時代においては量産されすぎてガンダムじゃない機体のほうが少ない
→G
→∀
→ナイト
貰いものだが俺はコイツがとにかく気に入って、リフィルを増やし止めヒモに飾りをつけ（新年に飾り壊れた、悲しい）栞代わりのヒモを追加で付けたし、ペン刺しと小さなボールペンを刺している。
最後に記帳したのは2018年です本当にありがとうございました。
いや無理、そもそも外出しないし外出時も手書きでメモする機会がまったくない。
でもさ、定期的に分解して表紙の皮にブラシをかけてミンクオイル塗って元に戻すのが楽しい、メンテナンスが楽しい。
まず使わないと思いながらもそれでも丁寧にメンテするのが悪くない時間なんだ。
一度虫歯になって削られた歯って、詰め物の下で虫歯菌が増殖していて
それにはどんなに歯磨きを頑張っても歯医者に定期的に通ってクリーニングや歯石取りをやってもらってもどうにもならないらしいとか。
歯の定期メンテナンスはあくまで歯周病のためだけのもので、虫歯は一度も虫歯になった事のない人への予防にこそなれ既に虫歯になった事のある人に対しては何の役にも立たないんだってさ
一度でも虫歯になったらその歯はもう一巻の終わりで、削って埋めたところで却って悪くなるだけならば
もう虫歯が発覚した歯は子供のうちにさっさと抜いて早い段階で総入れ歯にしてしまうのが一番合理的な気がする
なんでこう虫歯やその結果の歯根破折はいつも無視されて、歯を失う理由というと歯周病ばかりが注目されるんだろうか
もしかして、世間の人達って自分が思ってるよりもずっとずーっと、虫歯を一度も経験した事がない人が多い？
