「sla」を含む日記 RSS

はてなキーワード: slaとは

2024-08-19

ITがつまらなくなった」じゃなくて「お前がつまらなく感じる」だけだろ

IT がつまらなねーって、プログラマがいうのはプロ意識的にどうなんだろと思う

話題職業倫理ってどうしたよ、AIだけの問題なのか? そうじゃないだろ

というわけで、個人的に思うところをまとめてみる

生成AI の話に関して

生成AI で置き換えられるなら置き換えられればいいだろ

そうじゃない現在進行形価値は、過去から類推する生成AIでは作れない、だって元となるデータがないんだから

顧客にとって最適な、オーダーメイド価値提供できなければ、そりゃ簡便な手段代替されるだろう

それは AI に限ったことじゃないし、バーティカル SaaS とかで言われてきたことだろうに

そうじゃなきゃ生成AI代替されるというのは、至極当然のことだろう、今までの歴史からわかってるはずだろ

顧客に最適な価値提供できないことを、AIのせいにするなよ、つまらんこといってんじゃねーよ

ゲームエンジンの話に関して

ゲームエンジンの話にしたって、オレオレエンジンを作るレベルが上がっただけで、ゲームエンジンを作る仕事消滅してないだろ

適当な事をいうんじゃねーよ、大多数のゲーム必要としないからって、開発自体自体がつまらんと言い訳してるんじゃないよ

ゲームエンジンを内製するだけのゲームを作る気がないというのを、業界全体がつまらんという問題勝手に置き換えやがって

つまんねー論点のすり替えをするんじゃねーよ、プログラマとしてちゃんエンジン作らないと提供出来ない価値を考えろよ

必要としないんだったら、そこにゲームプログラマはいらないということで、そりゃお役御免なんじゃねーの? ツールいじるだけの仕事なんだし

クラウドサービスに関して

自分たち価値提供するということをおざなりにして、クラウドサービス限界自分たち限界にするのも腹が立つ

お前たちは GAFAM の奴隷で御用聞きなんですか?

Amazon提供してないから、Google提供してないから、Microsoft提供してないからって言い訳するの、恥ずかしくないの?

結局、リスクを負うことを避けてるからクラウドマネージドサービスを利用してるだけだろ、いい加減にしろ

SLA で返金されるからってノーダメからって、顧客に対して GAFAM の威光を利用してスネカジリしてるの恥ずかしいと思わないわけ?

クラウドベンダーが悪いんですっていって、最悪でも顧客に対して障害報告書を書けば済む業界は、そりゃ舐められるわけで

そういうのを、クラウドは可用性が...ってごまかすもの顧客にとってみれば関係ない話なのに、GAFAM の名前だせば許されると思うのは、流石に舐めてるだろ

メインフレームを扱ってる人のほうが、たぶんサービスを落とさないという観点において、プロ意識を持ってると思うよね、そりゃ

落ちちゃいけないんだから、落ちてもいいだろという人たちよりは、流石に神経使うだろうね

まとめ

自分技術が足りなくて価値提供できない事を、つまらないということこそダサいし、それがプロなんですかね?

ちゃん自分価値提供できていると思えるのであれば、そんなことを言ってほしくはないね

2024-02-02

anond:20240202225014

仕事ならSLAみたいなものを取り決める。

仕事じゃないなら、好きにして欲しい。やりかえしたら?毎回、100万円を請求しなよ

2023-12-23

anond:20231223083453 anond:20231223084404

基本的営業電話かかってくるのは、SaaSや一塊になったサービス(パッケージ📦って言いたいけど買い切り版みたいな意味なっちゃうからな)やハードを売ってる場合やで

なので、MicrosoftAmazonOracleCiscoDELLほか大企業(サポートエンジニア案件ごとに問い合わせ窓口はあっても直接相談できない)か、弱小ソフトウェアハードウェアメーカー、このどっちかやで

ほんで、弱小ソフトウェアハードウェアメーカーだと営業強制連行されることもあるってだけの話やね。一緒に会社デカくする気ないなら転職したほうがええぞ

なお、弱小じゃない場合営業から大口から気を付けて米!って言われることはあるけど、コンサル料もらってなきゃエンドのところになんか行きませんし、

解約したければどうぞご自由にってスタンスやぞ。営業くんに怒られちゃうから適当相手しますけどね

 

 

プロジェクト担当者SE電話かかってくるのはシステム開発運用受託してる時だね

まりSI下請けSESやね

SLAや各種契約書や設計書や運用フロー図や商流に沿ってご対応くださいとしか言えない

ちな、現在プロジェクト進めてる担当者SEじゃどうにもならないって判断されている時にしか

営業に鬼電みたいな流れには基本的にならないと思います

契約したらプロジェクトの窓口もお金管理SEがやるから

anond:20231222173011

謝罪だけですますとか一言も言ってないよ。

こちらに瑕疵があってリリースから一定期間の間はバグ修正責任こちらが負うでしょ。

そして契約の内容によっては、損害賠償も負うよ。SLAってそういうもんだから

おれの最初投稿は別次元もっと素朴な疑問だよ。

2023-12-22

anond:20231220212236

バグシステム死ぬというのは癌で人間死ぬのと同じだぞ

バグのないシステムはないんだから

SLA商売の話なので知らんけど謝ってどうこうで済むのか?

2023-12-20

anond:20231220144500

>> 癌で患者が死んだら医者謝るか?謝るべきだとおもう?

例えば単にガンで死んでたら別に謝まる必要はないだろうが、医療ミスだったら謝罪するでしょ。

それとおんなじよ。仕様による障害だったら謝ることはしないが、バグシステムが死んでSLAを満たせない場合謝罪しなきゃ行けないよ。

2023-06-14

anond:20230614183726

ドラクエ10利用規約は知らんけど、SLAでググってみるといいよ。

稼働率100%システム存在しないし、おかしいかおかしくないか基準がよく分からないな。

2023-02-20

anond:20230218154757

ITILを導入してサービスカタログとかSLA?OLA?とかカッチリ決めたいと思いつつ何もできてないなぁ

ってことを思い出した。そんな自分零細企業ヘルプデスク

Linuxサポートなんて絶対無理だわ・・・ Windows11の検証だって手が回らんのに。

2022-10-02

アンパンマンリスクマネジメントってガバガバすぎない?

資産価値

アンパンマン治安維持活動のもの

脆弱性

顔を濡らされるとアンパンマンは力を出すことができなくなる

潜在リスク

資産価値があるところに脆弱性があるので、かなり高いレベルリスクが潜んでいると結論できる

対応

ホットスタンバイ

アンパンマンの待機系または予備系を常時稼働しておく。頭を入れ替えても人格は引き継がれるので、メモリストレージの類は身体側にあると考えられる。ダウンタイムはないが高コスト

コールドスタンバイ

トラブル時に頭を入れ替えて再起動することで対応する。頭の予備が充分にある場合オペレータージャムおじさんが待機場所から現地まで行く時間がダウンタイムとなる。リモートでは対応できない。SLAで決められたダウンタイム以下であり、許容できる範囲内であれば安価

結論

アンパンマンが予備の頭を持ち歩けば良いのでは?

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

2022-01-03

法人インターネット接続サービス『NUROアクセス』が「速さ」と「安

ソニービズネットワークス株式会社(以下、ソニービズネットワークス)が展開している法人向けICTソリューション『NURO Biz』。

その中のインターネット接続サービス『NUROアクセス スタンダード』は低価格ながら、「下り最大2Gbps」「上り下り最低10Mbps以上の帯域を確保した帯域確保型回線」であり、新しい生活様式ニューノーマル)にも対応した、クラウド時代に最適な接続サービスとして注目を集め続けています

今回は、「安くて速い」を高いレベルで両立させる『NUROアクセス』をはじめとして、クラウドサービスAI製品を取り入れ、現代ビジネスを多方面からサポートする『NURO Biz』の魅力、さらには業界トップランナーとして目指すことについて、ソニービズネットワークスの渡邉大樹氏に伺いました。

――はじめに『NUROアクセス』が、どんなサービスかを教えてください。

渡邉:端的にいうと、「法人向けのインターネット接続サービス」です。光回線サービスとして、最大通信速度下り最大2Gbps、上り最大1Gbpsを実現しています。大きくわけて、エントリースタンダードプレミアムNEXT 10Gの4つのプランがあり、エントリー以外のプラン固定IPが1つ標準でついていることも特長です。

もっとも選ばれているのは「スタンダードプラン」で、ベストエフォート型ではなく、上り下り10Mbps以上の帯域が確保され、さらに下限値も保証された「帯域確保型回線であることがアピールポイントになっています

――『NUROアクセス』は法人にとってたいへん魅力的だと思います。では、『NURO 光』といった個人向けと法人向けの回線の違いを教えてください。

渡邉回線速度は両者とも「下り最大2Gbps / 上り最大1Gbps」なのですが、法人向けの回線には個人向けの回線にはない帯域確保やSLA(Service Level Agreement)があり、サポート体制もより充実しています。つまり個人向けの回線以上に”安定した稼働”を保証しています

また、ONU回線終端装置)にも違いがあります個人向け回線の『NURO 光』の場合ONUルーター機能付与されており、ブリッジモードにできないようになっていますしかし、法人向けの『NUROアクセス』ではONUブリッジモードになっているので、ご提供するルータースペックに左右されることなく、回線速度を最大限に活用いただけるメリットがあります

――やはり、法人回線の方が、遅くなったら困る、落ちて困るといった場面を作らないよう準備がされているのですね。

渡邉:そこは万全を尽くしていますインターネット回線世界では、実は「下限値の速度を担保する」ということに最もコストがかかりますコンシューマー向けだと、「最大何Gbps」等の広告が展開されていますが、そういったことよりも下限値をしっかり確保することが、ビジネス世界では特に重要だと考えられています

例えば、事務所インターネットを利用していると、通信速度は速いことが当たり前で、利用者の皆さんは何も気にしていないと思いますしかし、速度が低下して1Mbpsを下回ったりすると、おそらく利用者は速度の低下に気づきますし、仕事にも影響が出てきます

そういう意味でいうと、上り下り最低10Mbps以上の帯域確保ができるのは、『NUROアクセス 』の一番のウリだと思っています

タンダードプランは10Mbps確保、プレミアムプランは30Mbps以上の保証

――法人が『NUROアクセス』を利用するには、どんなプロセス必要ですか?

渡邉:まずお申し込みいただいて、その後に下見・工事…というのが基本的な流れです。関東では平時で1~2ヶ月、それ以外のエリアに関しては、3~4ヶ月を標準納期とさせていただいています。ただ現在は、社会情勢もあって『NUROアクセス』へのお問い合わせを多くいただいており、申し訳ないのですが標準納期より時間がかかってしまうケースもあります

最新の状況を確認するためにも、まずは弊社担当者にお問い合わせいただければと思います

――『NUROアクセス』の他の強み、アピールポイントも教えていただけますか?

渡邉面白いところは、スタンダードプレミアムプランではONU回線終端装置)までは下り最大2Gbpsで提供し、ONUにて最大1Gbpsの2ポート分岐しています。この2ポート物理的にも論理的IPサブネット)にも分かれているため、「1契約で、使える回線が2本ある」と言えます

実際、『NUROアクセス』を導入いただいたお客様のケースで多いのは、固定IPアドレスが付与される「LAN1」は業務用として執務スペースで使用し、「LAN2」の方はゲストWi-Fi等として開放するようなケースです。

――障害に強いことが『NUROアクセス』の採用理由になったという事例を拝見しました。耐障害性についてはいかがですか?

渡邉:もちろん、障害についても十分に対策するとともに、お客様サポートにも力を入れていますスタンダードプラン以上では24時間365日対応オンサイト保守サポートを用意していて、また1社に対して営業担当1人がつくことで、キメ細かいアフターフォローを実現できる体制を整えています

――『NUROアクセス』は非常に「ローコスト」なことでも話題です。法人向けの高スペック回線を、これだけ安く提供できる理由を教えてください。

渡邉2013年4月法人向けのICTソリューション『NURO Biz』サービスがはじまり、同時に『NUROアクセス』の提供スタートしました。当初から他社サービスベンチマークしていたことが、「高品質でローコスト」を実現できた要因だと考えています最近では、ベストエフォートギャランティを組み合わせたハイブリッド型のサービスを多く見ますが、『NUROアクセス』はそれらのハイブリッド型のサービス比較しても、非常にリーズナブルではないでしょうか。

さらに、スペックに関しても、「NUROアクセス スタンダード」については上り下り最低10Mbps以上の帯域確保を行うとともに、速度の平均値を計測し、結果を公表することで、自信をもって回線品質をお伝えしています

――速度を公表されている事例は少ないと思います利用者からすると導入前に「わかる」ことは安心に繋がりますね。

渡邉:実際に、法人お客様回線を切り替えることはかなり勇気がいることです。「価格が安くなっても、本当に大丈夫か?速度は出るのか?」と不安に思われるケースも多くあります。そのようなときに平均速度を公開していたり、下限値の保証があったりするのは「かなり参考になる」と、実際にご導入いただいたお客様からも伺っています

検討時に、定量的データに基づいて上申できることも、喜んでいただけているポイントひとつだと評価しています

『NUROアクセス』が幅広い業界企業に導入されている理由

――Webサイトを拝見すると、大学公共機関企業と、かなり幅広い業種で採用されています。実際にどのような業界企業で導入されることが多いのでしょうか?

渡邉官公庁から大学企業も、規模でいうとSOHOからエンタープライズまで、幅広くご利用いただいています。あえていうなら、情報通信業割合としては多く、従業員数では100~300名規模の企業様で導入いただくことが多いです。また、業種や規模によらず、動画コンテンツなどの制作編集をしているような、データ通信量が多い企業様にご利用いただいています

――やはり、回線速度に課題を感じている情報通信企業が中心ということですか?

渡邉基本的にはそうですが、今やすべての業種で、どうしても「インターネット」は必要です。例えば不動産業自動車販売業では、物件自動車写真だけではなく、Webサイト動画を公開して情報発信をする機会が増えています。今後、どのような業界であっても動画情報を発信することが主流になっていくので、幅広い業種で回線速度だけでなく、品質も求められる時代になっていくでしょう。

――たしかに。『NUROアクセス』の導入の中心は、やはりリプレイスでしょうか?

渡邉:そうですね。「回線の速度が遅くて困っている」という理由で、当社にご相談をいただくことが一番多いです。

COVID-19の影響でテレワークが増え、Web会議一般的になりました。しか回線速度が安定していないと会議が中断してしまますWeb会議が普及したこと、また安全かつ快適に社内システムを利用するためのインフラ整備という面で、通信回線重要度が企業の中で一気に高まりつつあるようです。

インターネットトラフィック量は年々増え続けています総務省Webサイトで『情報通信白書』によると、令和元年版では、2018年データ量に対して2021年はほぼ2倍になると予測されていました。

出典:世界トラフィックの推移及び予測(令和元年版『情報通信白書』より)

https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r01/html/nd112110.html

渡邉:その予測がされた次の版では、2019年には爆発的に増大したことが報告されています(令和2年版「情報通信白書」)。

出典:ブロードバンド契約者の総トラフィック(令和2年版『情報通信白書』より)

https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r02/html/nd131110.html

https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r02/pdf/n3100000.pdf

渡邉:新型コロナ禍の時代にあって、多くの人々が業務を「インターネット上で」行うことになり、今後さらトラフィックが拡大していくことが想定されます企業も、公共教育機関ネット回線の速度や品質を再検討し、さらなる高速化や安定化を求める流れになっているのかもしれません。

そんなトラフィックが激増するテレワーク時代でも、『NUROアクセス』なら安定して確実に接続できることは大きなメリットとだと確信しています

――『NUROアクセス』の導入事例に、ホテルWi-Fiサービスの強化に取り組まれたことが記されていました。今後は、こういった取り組みも増やしていくのでしょうか?

渡邉ホテルや、貸会議室といったお客様最近増えています出張ホテルに行ったり、会議室に入ったりした時にWi-Fi速度が遅いことは、お客様満足度の低下に繋がってしまますホテル会議室に限らず、カフェ学校など、公共の場で使えるインターネットへの注目度は上がっていくと考えています

2021-11-03

anond:20211103105417

ウィキペヨーロッパ各国を一通り調べてみた

アイルランド:Óglaigh na hÉireann(アイルランド国防軍)Óglaighの直訳は義勇兵なのでDefence Forceと訳される

ベルギー:Defensie(国防軍

ハンガリー:Magyar Honvédség(マジャール国防軍

フィンランド:Suomen puolustusvoimat(スオミ国防軍

エストニア:Eesti Kaitsevägiエストニア国防軍

ノルウェー:Forsvaret(国防軍

スウェーデン:Försvarsmakten(国防軍

アイスランド:Landhelgisgæsla Íslandsアイスランド沿岸警備隊

2021-08-14

anond:20210814161328

マルチクラウドSLA 下がるし、遅延やセキュリティ的に嫌いだね。一番イヤなのはAWS のりセーラーが入ること。なんのメリットあるねん。

2020-11-04

anond:20201104130642

レイヤーを専門とする会社は詳しくは知らんけどウェブ系のインフラは少なくても資格は見ないで、今までどういうことやってきたかを見る

例えばAWS/GCPで秒間数万を捌くインフラ設計したとか、SLAを高めるためにインフラでどういうことを気をつけてきたとか

パフォーマンスチューニング(SRE職だが)という点でアプリケーションインフラをどう絡めて直してきたかとかそこらへんの技術知識必要

あとインフラコストカットとかの話とかは割りと見る。それができない人だと正直戦力にならないか採用できない。

2020-08-21

anond:20200821010913

自分で調べたわ。悪いな。

あったけど、ユーザーから30日以内に報告しないと貰えないんだな。SLAってこんなもんなの?

https://gsuite.google.co.jp/intl/ja/terms/sla.html

Firebaseと格闘してたら一日が終わった、今日障害結構長かったね

てかG Suiteも障害出てたらしいけど、あれってSLAあるんだっけ?いや調べれば良いんだけどさ

2020-08-13

3D プリンタを買いたいと思った。

きっか

https://www.itmedia.co.jp/news/articles/2007/30/news134.html

この記事に触発された。3D プリンタが安くなっており個人で買って失敗してもチョット痛い程度の値段だったのが大きい。

あと、この記事SLA(光造形)タイプの精度が高いのも自分で使う分野(1mぐらいまでの鉄工業)で遊べそうかな?って思ったのも大きい。

コレによりより詳しく調査を開始することにした。

おおまかに

3D プリンタ出力には 3Dモデルデータ作成して 3D プリンタデータを渡して作る。

3D モデルデータ作成にはソフトウェアを使うがそれらには種類がいくつかある。

自分が使いたい分野は工場なので当然 CAD になる。

CAD ソフト

金を払う気はあまり無いので無料で使えるやつを探す

一番メジャーっぽいのが Fusion 360 だが、色々調べた結果自分が使うのは

とりあえずは FreeCAD というオープンソースソフトを使うことにした。

理由はうーん、まあ直感かな。まあ最悪乗り換えるし。

普通の人だったら素直に Fusion 360 みたいなメジャーソフトの方が

資料も多いしそっちの方が良いと思う。

周りに使ってる人が居るならその人と同じソフトだと質問できるしそういう面で決めた方が良いかと。

代替サービス

いくら安くなったとはいえ高いっちゃ高いので、その辺手軽に安く使ってみる方法は無いか探してみる事に。

以前あるゲームプログラマブログで使ってみたと書いてあったのを思い出したのが、 DMMサービス

https://make.dmm.com/print/

データアップロードして、注文するとそれが送られて来るというモノ。

素材も色々と選べるし、今回気になっている光造形樹脂もある。

とりあえず出来上がったモノがどんなモノなのか体験したいならコレが良いかも。

以下のサンプル品だと550円とクソ安いな。

https://make.dmm.com/item/1213611/

他にはレンタルスペースとかあるけど東京とかで遠いので厳しい。

買うとしたら何処で買うか。

とりあえずググると出てくるのが Amazon だが、現時点で買うとしたら SK 本舗かなと思った。

https://skhonpo.com/

理由は、詳細な日本語マニュアルが付くのが大きい。

他にも原料となるレジンも取り扱っている点や、サポートもしてくれる点も良い。

Amazon より割高だが上記マニュアルがありサポートもある点、

レジンが付いてたりしているのでその点を考えるとむしろ安いぐらいとの結論

買った後

買った後はバラ色の3Dプリンタ生活が始まる…訳では無く、大抵は何かしら失敗するらしい。

そもそも 3Dモデルデータからそのまま3Dプリンタに食わせられる訳では無く、

スライスソフトで「どう作るか」という情報を作る必要があるみたいで、

その際にもサポートをどこにどう付けるかというのもセンス経験必要らしい。

他にも、レジン(原料)の選定やその原料に合わせた3Dプリンタの設定(速度等)を模索する必要があるし、

現実環境温度湿度など)も影響があるのでその辺の模索必要とのこと。

やはり色々とデリケートでそう簡単に上手く行くようでもなく大変そうではある。

現状

3Dプリンターの価格はかなり安くなったものの、まだまだ発展途上…というより

まだまだこれからもっと便利だったり手軽だったりより細かいニーズ対応したりしそうな雰囲気を感じる。

自分の分野(1mぐらいまでの鉄工業)では、それなりの投資ノウハウ研究)が必要そうな気がする。

光造形タイプ場合温度管理等が重要材料温度が25度は必要なので冬場は結構厳しそうな感じ。

3DCAD勉強3Dプリンターとは分離して勉強しても良さそうなので、まずは 3DCAD勉強継続して、

3Dプリンタ情報を集めて機運高まってきたら買うんじゃないだろうか。

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