「インスタンス」を含む日記 RSS

はてなキーワード: インスタンスとは

2022-07-05

anond:20220704213243

社内のクラウドインフラを使って社内向けの数十PJ管理するアプリケーション提供していた。

管理者権限があったので、結構自由にいろいろできる状態だったんだけど、

ゴミインスタンスが増えたことに気づいて削除するスクリプトを書いて実行した。

次の瞬間DBを含むすべてのインスタンスが消えた。

手に汗どころじゃないくらいの冷や汗がでた。夢だといいなって本当に願ったけど現実だった。

なんでスクリプトで削除するなんていう危険作業動作確認もせず、ダブルチェックもせずにやってしまったのか。。。

すぐにエスカレーションした後、復旧できないか調査した。

30分ほど調べたらどうやら削除コマンドは本当の削除ではなく、インスタンスの停止になっていて1週間後くらいに本当に削除するなんていう

仕様になっていることがわかった。削除フラグを消してインスタンスを全部立ち上げることで半日くらいの停止で済んだ。

それ以降大きなやらかしはしていない。この失敗からかなり学んだんだと思う。

失敗からいろいろ学ぶから小さい失敗はたくさんしておいたほうが良いなと思ってる。

2022-06-27

anond:20220627104914

オブジェクトとかエンティティとかインスタンスとか、ふんわりした概念をみんなよくわからないままルー語でしゃべってるの草

2022-06-23

anond:20220622231602

この議論には相互性がない。あなたと同じように、相手のほうも相手でメインルーチンを走らせており、時にあなたを含む他者サブルーチン的に利用しているのだから

まりあなた側の視点だけで関わり合いのある他者機能的に命名してしまうと、あなたというドメイン内での局所的な命名のような命名が、同時に動作しているメインルーチン数だけ存在することになり、命名管理コストが爆発する(というか、事実上、できない)。他者あなたにとってのサブルーチン)が、あなたが定めた局所的な命名規則によって呼び出されることを保証できないのなら、それはプログラム的な意味での「呼び出し名」として成立していない。

よって、一意性がある命名を用いて、どのようなドメインからでもおおむね目的サブルーチンの呼び出しを可能にしていることには、合理性がある。増田のような視点で言えば、会社役職である「総務課長」や「営業主任」などは、相手が司る機能性に着目した命名とも言えるが、そうした役職は同時に複数存在しうるので、個別インスタンス指定して呼び出すには、やはり一意性がある命名を利用することが合理的だ。

また、他者の「機能」は自分との関係で変化する。機能が変わるごとにサブルーチンとしての他者呼び方を変更することは、両者がドメイン(たとえば家庭)を共有している場合は低コスト可能だが(たとえば子供ができたあとに互いを「パパ・ママ」呼びするなど)、そうでない場合は、機能が変わるたびに命名を変えるのは、メインルーチン側から見ても合理的でない。

人間他者との相互通信コストを最小化するには、「他者機能命名して、変更があった場合は頭の中でテーブルを書き換える」より、「お互いにユニークに定められたマシン名を直接叩く」ほうがよいのだ。

2022-06-22

vrchat飽きてきた

始めたときにpublicで会った人たちの輪に入れたが、慣れてきてもずっとpublicにいるから毎度毎度初めましてのユーザーが多くて会話を新しく始めるのに疲れた

他の輪に入ろうにもユーザーランクが上がってしまって腰が上がらない

日頃から適当に話せるフレンドが決まってきたしpublicインスタンスから移動したいが、フレンドにその声をかける勇気もない

真のコミュ障仮想現実でもコミュ障

2022-06-14

anond:20220614152109

クラッシュしたインスタンス世界は全て破棄され、過去バックアップクローンされて再開される・・・

俺たちはそんな世界に住んでいる。

2022-05-13

ずぼらな人にクラウドは向いていない。無料枠のつもりなのに課金され

Google Cloud Platformで無料枠で最小インスタンスを使っているつもりで、2019年からやっていたのだけど、設定も一切変えていないはずなのに、2021年3月から急に課金がされていったぽい。

2021年3月 ¥152

2021年4月 ¥151

2021年5月 ¥165

2021年6月 ¥191

2021年7月 ¥210

2021年8月 ¥273

2021年9月 ¥692

2021年10月 ¥685

2021年11月 ¥677

2021年12月 ¥749

2022年1月 ¥758

2022年2月 ¥692

2022年3月 ¥713

2022年4月 ¥529

6637円+今月600=8237円

勉強代としてはそこそこ高いな。

泣きたい。 ;_;

クレカの総額だけ見て、明細をチェックしないで、無料枠だから安心していたのがまずかった。

発端は、クレカ不正利用だった。

いきなりクレジットカードが使えなくなって、問い合わせしたら、不正利用されていたっぽい。

いったいどこから漏れたのかわけわからんが、知らない所で5万円の商品の購入があったみたいで、そんなの買っていないので、取り消しをして一件落着・・・なはずだった。

ただ、直近の課金の内容をオペレーターと1件ずつ確認していたんだけど、Google Cloudから529円請求がありますねと言われて、無料プランなのにそんな馬鹿なと思った。

今月だけではなく先月もあるし、先々月もあると。

おいおい嘘だろうって思った。

そして、ちゃんと調べてみると、上記のとおりの請求書がメールの山の中に埋もれていた。

2019年から利用してて、ずっと課金が発生していなかったので、無料プラン範囲だと信じていたので、確認がザルだった。

とりあえずサポートに何で2021/3から課金されているの?ってメールは送ったけど、回答はあまり期待していない。

クラウドはずぼらな人には向いていないんだなと再認識した。

クレカ登録するなら毎月ちゃん確認しないとヤバいなあ。

お前らも注意しろよ。

それと、ずぼらな人がクラウドを使う上でのアドバイスを求む。

2022-05-05

anond:20220505204559

からだけどステートフルなプロトコルを使うとこは仕方なくインスタンス立てることある

WebSocketとかWebRTCとか

サーバレスに寄せられるとこはできる限り寄せるけどね

FWとかルーティングとかOSパラメータとかストレージ容量のアラートとか毎回設定するの面倒くさいじゃん

anond:20220505024023

そうしておけば、放置できる。自前で立てたマシンインスタンスもないから落ちてるかどうかとか気にしなくてもいい。負荷も考えない。

ちなみにこちらは 1日数十アクセスの過疎サイト

負荷とか落ちてるとか(そんなに)気にしなくていいのでは・・・

anond:20220504211823

★★再追記

レンタルサーバは、自由度が低くてストレスになるからやらない。SQLでwith使いたいかMySQL8をって言ってもさくらレンタルサーバじゃ無理なんでしょ? あと同居利用者のせいで高負荷ってのも避けたい。そこを気にしない人はレンタルサーバでいいと思うよ。

あと LB $0.025/h だった。月2000円くらいか

追記

LBは独自ドメイン+自動更新無料SSL証明書のためね。Cloud Storageの無味乾燥ドメインでいいなら、SSL自動かつ無料でほんとに月数円。

-------

もうねめんどくさいんだわ。もちろん以前はそうやってたよ。

PHPだのApacheだのMySQLだのインストールしたり設定ファイル置いたり、

脆弱性対応したり、SSL証明書更新したり、一応落ちてないか無料監視サービス使ったり。

でも仕事ならともかく、趣味からこそこんなことやりたくないじゃん。

なので、コンテンツは Cloud Storage に置く。

Cloud Load Balancing も使う (無料 SSL 証明書のために)。

認証必要なところは Cloud Identity で。

動的部分は Cloud Functions で。

AWS なら S3+ALB+Cognito+Lambda だな。

そうしておけば、放置できる。自前で立てたマシンインスタンスもないから落ちてるかどうかとか気にしなくてもいい。負荷も考えない。クラウド様がよきにはからってくれるさ。たまにクラウド障害あるかもしれないけど、Google なり AWS なりが頑張って直してくれる。

って感じ。

ちなみにこちらは 1日数十アクセスの過疎サイト独自ドメイン+自動SSL証明書にするための Cloud Load Balancing に 4000円くらい払ってる。それがなければ月数円。

2022-04-27

anond:20220426213943

文字が読めない増田は非常に面白いギャグかますよね🤣 

ワイの一番古い増田DHCP理解してないマン宛のトラバやったで

2018-08-14 anond:20180814213814

IPを、MACアドレスに機種名と紐付けて帳簿で管理するのはまず無理だな。

あとユーザ使用許可を出すIPの個数を可能な限り制限したいから、その意味でも管理不可能だな。

RadiusActive Directory も無い世界線どころか、DHCPサーバ側でMACアドレスIPアドレスの組み合わせを予約しておくことすらできない世界線増田

 

最近でも Azure AD なんか導入している企業ないマン、Microsoft365 や Google Workspace は存在しない+それらと連携させるセキュリティプロダクトは存在しないマン

AWSVMDocker存在しない世界線マンAWS で起動テンプレートを作らないインスタンスを複製しないマンDebian契約するマン

Linus Torvalds を知らないマン資産管理意味理解できないマンフリーデスク基本的運用を知らないマン、基幹システムアクセスしないマン

Teamsなどのコミュニケーションツール存在しない世界線マン、今時は Teams などのコラボレーションプラットフォームに内線を統一する流れなのに

一昔前の BYOD個人携帯アプリで内線を割り当てるどころか固定電話廃止して携帯定額通話ドヤ顔マンユニコーン企業で働いてる設定なのにお局云々マン

AWS年収1000万余裕マンAWSについての歴史改変マン既存不正検知AIプラットフォーム使用せず依頼を受けてサイゲ参考に不正検出システムを作ったマン

Python仕事は無いマン・・・・・ほか、上げたらキリがないんだわ

 

とりあえず、時が止まり過ぎ+IT業界に妙な憧れがあることだけは伝わる

因みになんだがこれやってるのすべて同じ増田なんじゃ無いか?って思ってるよ。文字文字通り読めない増田

このレベル増田がたくさんいるとは思いたく無いわ

 

もちろん、だからといって、増田に書き込んじゃダメってことは一切ない。今まで通り好きなこと書いたらいい

ただ文字を読めない自覚常識がない自覚はあっていいと思う

その自覚さえあれば、在りし日のVIPがみんなニートという体だったのと同じく、

ワイも増田

MMMO (M 無教養で M 無能で M 無収入な O オタク) か

MMMM (M 無教養で M 無能で M 無収入な M マン) で

それ以外はフェイ!!!でええやろ

2022-04-26

twitter有料化によりマストドン に俄かに脚光が

なんてあるだろうか

今、日本人ユーザが多いインスタンスってどこなんだろう、

とググってみたが出てくる情報古いなぁ

2022-04-15

アトラシアン障害、いったいどんなデータ管理してたのだろうか

マルチテナントDBインスタンスを共有?想像もつかん

Kubenetisでリソース自動配置しとかしてたのだろうか

詳しい人だれか教えて

2022-03-31

ワンストップでのサポート力が強み

 まずは、日立サーバーでのWindows Server 2022への対応からお聞きした。

木村サーバーにはHA8000VとRV3000の2ラインアップがあります。HA8000VがPCサーバーで、汎用的なサーバーとして、エントリー向けや、HCI、VDIのソリューションなど、いろいろな用途で使われています。RV3000はミッションクリティカル向けです。Windows Server 2022のプレインストール対応は、HA8000Vの全機種で2022年5月を予定しています

日立サーバー製品ラインアップ

Windowsサーバー市場における日立の強みとして、木村氏は、サポート力を挙げる。

木村日立は長年に渡ってプラットフォーム製品の開発を行ってきました。作ってきたからこそ、中身がわかっている技術力があります。できることとできないことを技術者がわかっているので、障害が起きたときや問い合わせのときに、お客様事実真摯に伝え、重大な不具合があっても技術力で解決に向けていきます。何かあったとき問題たらい回しにせず、技術力をコアにしてしっかり対応するサポート力が強みです。

 こうした日立DNAを結実させたサポート商品が「日立サポート360」だ。通常はサーバーハードウェアからOSソフトウェアなどは、それぞれと契約し、サポートを受けることになる。日立サポート360ではこれらをワンストップで受け付け、支援することができる。

広瀬: 窓口が1つになるというのは他社でもありますが、そういう表面的な話だけではなく、複合的な力で問題解決支援にあたれるのが真の価値です。内部で、サーバーからOS日立ミドルウェア、導入ミドルウェアなど、いろいろな製品部門連携がすごく濃密にされているからこそ、複合的な力で問題解決にあたれます。これが本当のワンストップ意味です。

ワンストップサポート体制

 この日立サポート360Windows Server 2022のサポートにも対応する。日立では、長年のサポート実績により蓄積された技術力により高い自社解決率を誇るという。自社解決率が高ければ、それだけパートナーへのエスカレーションが減るわけで、短期間でのトラブル解決が期待できることになる。

日立ハイブリッドクラウドソリューション「EverFlex from Hitachi

 木村氏は、日立ハイブリッドクラウド戦略としてEverFlex from Hitachi (以下、EverFlex)ソリューション説明した。EverFlexは2021年10月クラウドとのデータ連携ソリューションとして始まり2022年2月ハイブリッドクラウドソリューションとして強化された。

木村お客様オンプレミスパブリッククラウドを使うときに、最適なシステム設計にして、コスト最適化していきますハイブリッドクラウドの導入には事前にアセスメントコンサルティングを行うことが大切です。なぜなら、パブリッククラウドを導入することで負担が減るかと思われがちなのですが、ハイブリッド化されることで負担が増えることがあるからです。

 EverFlexの特徴の中でも特にクラウドライクなサービス提供」について木村氏は紹介した。

木村ハイブリッドクラウドになると保守運用煩雑になりますパブリッククラウドオンプレミスの両方を管理しなくてはならないため、システム管理において両方のノウハウ必要になります。このため保守運用フェーズにおいて簡単化されずコスト最適化課題となってきます。それを避けるために、共通化するニーズに応えるようにいろいろと工夫しています

ハイブリッドクラウドソリューションEverFlex from Hitachi

 まず、問い合わせをワンストップ化したり、運用管理を1つのツールで一元化したりすることで、顧客負担を軽減する。

 プラットフォームにおいては、オンプレミスからクラウド接続可能にしてシームレスにお互いやりとりできるOSが各社ある。Windows Server 2022はまさにそれを特徴としており、同じくAzure Stack HCIも選択肢に入る。

 さらに、支払い/利用形態についても、オンプレミスでも売り切りだけでなくフィー型も採用する。こうしたEverFlexの中でWindows Server 2022のユースケース木村氏は2つ挙げた。

 1つめは、運用管理簡単化の部分で、Azure Portalからオンプレミス管理できる機能の強化だ。

木村オンプレミスエージェントを入れておけば、管理者がAzure Portalだけをさわって、オンプレミスリソースイベント管理も全て一元化できます。これに期待しています

 もう1つはセキュリティの強化だ。

木村ハイブリッド化が進むと、両方の基盤をネットワーク接続することになります。従来には存在していなかった接続となるため、その部分でセキュリティの強化も進めなければなりません。そこでWindows Server 2022では、Secured-core ServerによってOSのものセキュリティレベルが上がっていますTPMと連動する機能によってハードからOSレイヤーを守り、マルチレイヤーセキュリティを強化しています

Windows Server 2022のユースケース

 そのほかにクラウドライクの取り組みとして2つを木村氏は紹介した。

 1つめは「サーバ予備リソース提供サービス」。サーバーを余分に設置し、支払いは電源を入れて使った月だけ発生するというサービスだ。

木村: 迅速でタイムリーリソースを増強したいときに、クラウドなら自由構成を変えられます。それをオンプレミスでもできるようにします。クラウドではインスタンス単位となり、ハードウェア構成メニューの中から選択することになりますが、オンプレミスでは構成自由に組む事ができます。まずHCIソリューションから開始しましたが、2022年4月からはそれ以外にも拡大する予定です。

サーバ予備リソース提供サービス

 もう1つが「ハードウェア安定稼働支援サービス」。オンプレミス環境サーバー運用管理を省力化するものだ。

木村: 旧来の保守では、ファームウェアバージョンアップがあると、技術的にどういう影響があるかを確認して、その都度適用するかどうかを判断する必要がありました。それを提供元が判断するのがこのサービスです。お客様機器を弊社で管理して、ファームウェアの推奨バージョンの選定や、更新作業などを一括でやります

ハードウェア安定稼働支援サービス

サブスクリプションに力を入れる

 日立のこれからの注力分野について木村氏は、サブスクリプションに力を入れていくと語った。

木村: 全社的な方針で、サブスクリプションに力を入れていきますクラウド化で初期投資をおさえるニーズと同時に、オンプレミスも求められています。そうしたお客様ニーズにアラインしていきます

 サブスクリプションクラウドライクなサービス管理簡単にして顧客企業コストを抑えることで、究極的な目的はその先のDXだと木村氏は語る。

木村既存プラットフォームコスト最適化させ、浮かせた費用を新たな投資先として、AIEdge活用する新たなデジタルソリューション領域に向けていくことを支援していきたいと考えています

 そのために木村氏は、よりハイブリッドで使いやすいようなライセンス体系をマイクロソフトに期待している。

木村: 今後ハイブリッド化が進むと、繁忙期にリソース拡張するといったこともあります。そのときライセンスが、オンプレミスオンプレミスで買って、AzureAzure課金してと、ハイブリッドで使いづらい体系になっています。将来的にライセンス体系を統一するなど、両方の基盤で使えるような体系になることを期待しています

 また、Azure Portalからオンプレミス管理できる機能についても、さらなる強化を木村氏は期待する。

木村Azure Portalから管理できる範囲に限りがありますOSから上のリソースイベント監視できるのですが、ハードウェアの死活監視や電源管理などは対応していないため、JP1やその他のツールなど、複数ツールを使いこなす必要があります。それらの管理ツールが乱立してしまうと、また管理の手間が増えてしまう。こういったことをオンプレツールか、Portal側で統一することも期待したいところです。

2022-03-11

anond:20220311102012

クラス名やメソッド名が長いのは問題にならないけど

コールバックを渡すのにわざわざAdapter継承したクラスを作ってインスタンス化して設定、とかありえん面倒臭さだった

2022-02-27

anond:20220226180821

やあ、

https://anond.hatelabo.jp/20220226180821元増田だよ。

安酒飲んだ勢いで適当に書いた「はてブプレミアム」案への各種感想ありがとう

更に上位の「はてなブックマークプラチナム」案も思いついたからざっくり列挙するよ。

---

弁護士特約プラチナム訴訟案件年2回+発信者情報開示請求プロテクション年3回まで付与。専用カラースター購入のち充当で回数復活)

はてな匿名ダイアリープラチナムプレミアムの特典全部+専用サーバーで楽しく匿名日記

はてブTorプラチナムな達人向けの試験機能情報セキュリティに興味はある? はてなidと強固に結びついたセキュアかつサクサクTor鯖を使いこなそう!)

はてブ丼(プラチナムあなただけのMastodonインスタンスで他のユーザーと差を付けよう! ※一部の単文トゥートは自動的に公開状態ブクマされ、一部の長文トゥートは匿名ダイアリー自動的投稿されます

はてブ電話(※物理SIMのみ数量限定先着順。ブックマークサービスなのに電話番号が貰える!? そう、プラチナムならね)

・eはてブ電話(↑のeSIM限定版。ブックマークサービスなのに以下略

はてブ自警団はてブヘビーユーザー待望の自警機能利用規約違反かつ人倫にもとるブコメ投票非表示にしよう! 自警ランキングサービス開始と同時に公開。自警上位10アカウントにはなにかいい事あるかも?)

2022-02-23

anond:20220223091601

人間オワコン

AIにより固有の人格記憶インスタンスを持った二次元彼氏彼女との結婚生活けが人類幸福にできるんだぞ

分かったら男女ともに総力を挙げて次元の壁を超える技術を開発していけ

人気の人間にだけ異性が集中する不均衡を是正できるのはこの二次元インスタンスによる非対称ソリューションしかないんだぞ

2022-02-10

anond:20220210184443

やりたいことにもよるけど、DBテーブルから対応する値を引っ張ったりとか、ポリモーフィズムインスタンスを切り替えたりとか。

if,elseif,elseif,elseif,elseif,とか、swicth case,case,case,case,みたいに、else if, caseあんまりずらずら並べないほうがいい

2022-01-25

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービス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の登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービス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の登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

2021-12-15

デストラクタはどこに定義するか

オブジェクト指向言語ではクラスインスタンスが破棄される時にデストラクタが呼ばれる。

(呼ばれない言語もあるのだろうか?)

disposeだとか、deinitだとか、~○○○ (クラス名が入る) だとかいうあれ。

あれってどこに置くべきなんだろう。書くとき一瞬悩む。

ログイン ユーザー登録
ようこそ ゲスト さん