  |
はてなキーワード: slaとは
基本的に営業に電話かかってくるのは、SaaSや一塊になったサービス(パッケージ📦って言いたいけど買い切り版みたいな意味になっちゃうからな)やハードを売ってる場合やで
なので、MicrosoftやAmazonやOracleやCiscoやDELLほか大企業(サポートエンジニアへ案件ごとに問い合わせ窓口はあっても直接相談できない)か、弱小ソフトウェア・ハードウェアメーカー、このどっちかやで
ほんで、弱小ソフトウェア・ハードウェアメーカーだと営業に強制連行されることもあるってだけの話やね。一緒に会社デカくする気ないなら転職したほうがええぞ
なお、弱小じゃない場合、営業から大口だから気を付けて米！って言われることはあるけど、コンサル料もらってなきゃエンドのところになんか行きませんし、
解約したければどうぞご自由にってスタンスやぞ。営業くんに怒られちゃうから適当に相手はしますけどね
プロジェクトの担当者SEに電話かかってくるのはシステム開発運用を受託してる時だね
SLAや各種契約書や設計書や運用フロー図や商流に沿ってご対応くださいとしか言えない
顔を濡らされるとアンパンマンは力を出すことができなくなる
資産価値があるところに脆弱性があるので、かなり高いレベルでリスクが潜んでいると結論できる
アンパンマンの待機系または予備系を常時稼働しておく。頭を入れ替えても人格は引き継がれるので、メモリやストレージの類は身体側にあると考えられる。ダウンタイムはないが高コスト。
トラブル時に頭を入れ替えて再起動することで対応する。頭の予備が充分にある場合、オペレーターのジャムおじさんが待機場所から現地まで行く時間がダウンタイムとなる。リモートでは対応できない。SLAで決められたダウンタイム以下であり、許容できる範囲内であれば安価。
アンパンマンが予備の頭を持ち歩けば良いのでは？
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
ソニービズネットワークス株式会社（以下、ソニービズネットワークス）が展開している法人向け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以上の帯域確保を行うとともに、速度の平均値を計測し、結果を公表することで、自信をもって回線の品質をお伝えしています。
――速度を公表されている事例は少ないと思います。利用者からすると導入前に「わかる」ことは安心に繋がりますね。
渡邉：実際に、法人のお客様が回線を切り替えることはかなり勇気がいることです。「価格が安くなっても、本当に大丈夫か？速度は出るのか？」と不安に思われるケースも多くあります。そのようなときに平均速度を公開していたり、下限値の保証があったりするのは「かなり参考になる」と、実際にご導入いただいたお客様からも伺っています。
検討時に、定量的なデータに基づいて上申できることも、喜んでいただけているポイントのひとつだと評価しています。
――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速度が遅いことは、お客様満足度の低下に繋がってしまいます。ホテルや会議室に限らず、カフェや学校など、公共の場で使えるインターネットへの注目度は上がっていくと考えています。
https://www.itmedia.co.jp/news/articles/2007/30/news134.html
この記事に触発された。3D プリンタが安くなっており個人で買って失敗してもチョット痛い程度の値段だったのが大きい。
あと、この記事の SLA（光造形）タイプの精度が高いのも自分で使う分野（1mぐらいまでの鉄工業）で遊べそうかな？って思ったのも大きい。
コレによりより詳しく調査を開始することにした。
3D プリンタ出力には 3D のモデルーデータを作成して 3D プリンタにデータを渡して作る。
3D モデルデータの作成にはソフトウェアを使うがそれらには種類がいくつかある。
一番メジャーっぽいのが Fusion 360 だが、色々調べた結果自分が使うのは
とりあえずは FreeCAD というオープンソースのソフトを使うことにした。
普通の人だったら素直に Fusion 360 みたいなメジャーなソフトの方が
資料も多いしそっちの方が良いと思う。
周りに使ってる人が居るならその人と同じソフトだと質問できるしそういう面で決めた方が良いかと。
いくら安くなったとはいえ高いっちゃ高いので、その辺手軽に安く使ってみる方法は無いか探してみる事に。
以前あるゲームプログラマのブログで使ってみたと書いてあったのを思い出したのが、 DMM のサービス。
データをアップロードして、注文するとそれが送られて来るというモノ。
素材も色々と選べるし、今回気になっている光造形樹脂もある。
とりあえず出来上がったモノがどんなモノなのか体験したいならコレが良いかも。
https://make.dmm.com/item/1213611/
他にはレンタルスペースとかあるけど東京とかで遠いので厳しい。
とりあえずググると出てくるのが Amazon だが、現時点で買うとしたら SK 本舗かなと思った。
他にも原料となるレジンも取り扱っている点や、サポートもしてくれる点も良い。
Amazon より割高だが上記マニュアルがありサポートもある点、
レジンが付いてたりしているのでその点を考えるとむしろ安いぐらいとの結論。
買った後はバラ色の3Dプリンター生活が始まる…訳では無く、大抵は何かしら失敗するらしい。
そもそも 3Dモデルデータからそのまま3Dプリンタに食わせられる訳では無く、
スライスソフトで「どう作るか」という情報を作る必要があるみたいで、
その際にもサポートをどこにどう付けるかというのもセンスや経験が必要らしい。
他にも、レジン（原料）の選定やその原料に合わせた3Dプリンタの設定（速度等）を模索する必要があるし、
現実の環境（温度湿度など）も影響があるのでその辺の模索も必要とのこと。
やはり色々とデリケートでそう簡単に上手く行くようでもなく大変そうではある。
3Dプリンターの価格はかなり安くなったものの、まだまだ発展途上…というより
まだまだこれからもっと便利だったり手軽だったりより細かいニーズに対応したりしそうな雰囲気を感じる。
自分の分野（1mぐらいまでの鉄工業）では、それなりの投資（ノウハウの研究）が必要そうな気がする。
光造形タイプの場合、温度管理等が重要で材料の温度が25度は必要なので冬場は結構厳しそうな感じ。
3DCAD の勉強は3Dプリンターとは分離して勉強しても良さそうなので、まずは 3DCAD の勉強を継続して、
Z君と仕事をするようになって僕は雨男という存在を信じるようになった。
雨男と言っても、本当の天候の渕上様的な意味での雨男ではなく、「彼が参加したプロジェクトにはことごとくトラブルが発生する」という意味でだ。僕が知る限りでも、いくつかの転々としたプロジェクトやチームで
などなど、枚挙に暇がない。原因をたどると必ずしも彼一人の責任とばかりは言えないものだったり不可抗力的なものだったりする。にも関わらず彼のいるところでは明らかにそういうトラブルが頻発するので雨男なのである。
でも正直言うと、僕はやっぱり原因は彼にあると内心思っている。彼はとにかく粗忽で人並み外れてミスが多い。数行のメールの中で一行目と二行目で矛盾したことを書く。指示をことごとく間違って解釈する。やらなくていいことをわざわざやってミスを作り込む。報告の内容が何度聞いても要領を得ない。そしてミスや問題を隠す。一つ一つのエピソードは笑えるものもあるし新人の可愛い女の子だったらドジっ子キャラで愛されるかもだけど、この業界で10年以上経験があってこれはどうなの。
と書くと絶対「ミスは誰にでもあるもの、チェックやレビューする体制をしっかりすべき、報告を隠さないような雰囲気を作れ」と言われるでしょう。うんわかりますよ、全くその通りだと思います、一般論としては。でもかなりのことはすでにやっていて、それでも彼の粗忽っぷりはさらにその斜め上を行っているので結果として周囲の負担がさらに大きくなっている。それがトラブルを招きこむ要因になってるとしか思えない。
彼は今は別の組織に異動したので今はうまくやっているのかよくわからない。やっぱり使えないと言われて突っ返されてこないことを祈るのみだ。
