はてなキーワード: 拡張とは
最初の会社はoutlookでメールのフォルダ分けに苦悩した。
初めの転職先はg suiteだったんだが、ラベルに感動した。
ラベルは1つのメールに複数付けれるというのが大きなメリットだ。
一つのメールに2つ以上の用件書いてくるやつがいれば、outlookではメールをコピーして2つのフォルダにそれぞれ放り込んでいた。
メールが2つに増えるせいで検索時に余計にヒットするわ、削除したつもりで、コピーが残っているとか、くそめんどくさかった。
gmailだけでもかなり複雑なルールも設定可能で、GASまで使えばメール整理にまったく手間がかからなくなった。
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。
【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から見ると単に1つのプロセスが稼働している扱いになる。
【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%増加する、という任意のステップに従ってタスク数を増減させる
増田を見るときは、Chromeの拡張「コンパクトな増田」を利用し、長文もしくはトラバではない増田だけを見るのだが、実際ちゃんと見るには、すべての増田に目を通す必要がある。
いやはや頭が下がるなあ・・・
去年1年間、ブクマカをしていた。
2021年のブクマカのスター獲得ランキングに入っていたし(1万スター以上獲得)、それなりに活動していたと思う。
加えて増田のファーストブクマもしていた。2021年ファーストブクマカランキングに入っていたので、ファーストブクマカと言っても差し支えないないだろう。
あと増田も投稿していた。こちらはあいにくあまり活躍できず、2021年増田文学にかろうじて1つランクインしたくらいだった。200ブクマくらいなら数十件あるが、1000ブクマの壁は厚い。
それでなぜブクマカを半分引退したかというと、理由はいくつかある。
ニュースでも増田でも、これは伸びる、という記事がある。その記事の初めの方にするコメントは、基本的に伸びやすい。ここで変なコメントをすると、「トップコメはおかしい」などと吊るし上げられることすらある。だから初めの方にするコメントは割と推敲する。スターがもらいやすいのは、みんなの気持ちを代弁するようなコメント。すると、「自分が言いたいことはこのコメントが言ってくれてるから星をつけておこう」となるからたくさん星がもらえる。
そんな形で俺はスターを集めていたのだが、これが結構疲れる。ブクマカの気持ちを想像し、それを100文字でまとめ、早い段階でコメントをする必要があるので、エネルギーを使うのだ。またこれとは別に大喜利的な回答にしても、長文じゃないと人気コメントにならないので、長文の大喜利を考えないといけない。そんなこんなでブコメするのに疲れてしまった。
増田を見るときは、Chromeの拡張「コンパクトな増田」を利用し、長文もしくはトラバではない増田だけを見るのだが、実際ちゃんと見るには、すべての増田に目を通す必要がある。トラックバックに面白い増田がある場合もあるからだ。しかしこれがかなり精神に堪える。増田の大半はネガティブな内容なので、それに目を通すのは実際病んでしまう。しかも自分が良いと思った増田にファーストブクマしても、伸びないと結構悲しい。
また自分がファーストブクマしなくても、他のファーストブクマカがブクマしてくれてる場合も結構ある。なんだ、俺はいらないんじゃないか、そう思ってファーストブクマカもやめた。
今はブックマークもコメントもせず、はてなブックマークの人気エントリやコメントを読むだけにしている。ROM専だ。ただ増田にだけは時々投稿している。トラックバックはせず、自分の思いついた日記を単体で投稿する。数日後に伸びていてトラバやコメントが付いていると嬉しいしありがたい。
俺にはこの距離感が丁度良いのかもしれない。実際、前はブクマに依存していた。どこか、「はてブが俺の居場所。ブクマカや増田は俺の理解者」みたいになっていた。いやいや、これは危ない傾向だ。ブクマカや増田は個人ではないし、集合体だ。個人的に付き合うものではないし、時には斧が飛んでくる。そんなものに依存しちゃいけない。適度な距離を保って付き合うのがいい。
まあそんなことを言いながら、またブクマカをするかもしれない。だからタイトルに「半分引退」と書いた。俺がはてブに依存しないようになれれば、また戻ってくるかもしれない。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
275あとで/2648users 賃貸住宅退去時トラブルの印籠になるガイドライン、金額の負担区分がめちゃ明確なので覚えておくとよい「印刷して手持ちは必須」 | Togetter
274あとで/1445users 超凄いIPv6解説書(488ページ)を無料配布します!:Geekなぺーじ
240あとで/2165users 身近な人が亡くなった直後に「やってはいけないこと6選」 | DIAMOND online
236あとで/1610users お金の勉強はどこから始める?あなたの目的に合った具体的な勉強方法を紹介 | ゼロから始める投資アカデミー
209あとで/1454users 【1日15分】下腹部を引き締める、5つの体幹トレーニング|器具なしで自宅で可能 | Esquire
200あとで/1364users オオタジュンヤ氏の作図した「クラシック音楽史とポピュラー音楽史」の情報量が膨大過ぎてもはや教材になるレベル | Togetter
200あとで/1738users 2021年「はてなブックマーク年間ランキング」トップ100 - はてなニュース
194あとで/1388users この本がスゴい!2021 | わたしが知らないスゴ本は、きっとあなたが読んでいる
184あとで/1668users じゅじゅ on Twitter: "年末年始、なにか勉強したいな~と思っている方向けに完全無料で高品質の内容が学べるコンテンツをまとめました🎄 英語、統計・データ分析、IT・プログラミング、ロジカルシンキング、会計・ファイナンスなど。 こんなに最高なコンテンツが完… https://t.co/aM91f9DpHk"
180あとで/1792users 平成元年発売のテトリスの世界大会が 今大変なことになっている|slappin' Notes|note
169あとで/1165users リスクの洗い出しと判断のコツ - やしお
168あとで/1755users なぜエンジニアが作る画面はダサいのか…?「理由」と「対策」を徹底解説【エンジニア向け画面デザイン講座】 - Qiita
165あとで/900users Python言語による実務で使える100+の最適化問題 | opt100
163あとで/887users 東京工業大学、機械学習の講義ノートが無料公開 Pythonの実装も学べる | Ledge.ai
158あとで/589users 「あとで読む」タグで振り返る2021年 〜今年の「あとで読む」、今年のうちに〜 - はてなブックマーク開発ブログ
157あとで/929users 増田文学 2021年 | anond.hatelabo.jp
147あとで/920users 2021年、企業が無償公開した新人エンジニア向け研修資料 機械学習やゲーム開発、AWS入門、数学などさまざま | ITMedia
144あとで/1198users “難しい人”が1人入ると、チームの生産性は30〜40%低下する 対抗せずに、場の「安心感」を作るための3つの条件 | 斉藤徹 | logmi Biz
140あとで/1243users DeepLの”公式”Chrome拡張がヤバイ。TwitterもSlackも英語でつぶやき放題 | DevelopersIO
137あとで/997users 撮影時に知っておけばバランスが良くなる構図の12つのパターンが思わず使いたくなる。「それっぽく見えるレイアウト」や「視線を誘導させるレイアウト」も | Togetter
135あとで/946users 数学とプログラミングの勉強を開始して、何度も挫折して今に至る軌跡を晒す | anond.hatelabo.jp
134あとで/1340users 【更新】大の紅茶好きによる「価格帯別オススメのアールグレイ」プレゼンが素晴らしく有益 | Togetter
133あとで/902users 多摩美術大学が、誰もが参加できる“デザインの大学”を期間限定開校。50の新たなデザイン領域を知る、講義プログラム公開 | 多摩美術大学 | PR TIMES
131あとで/679users 良いコードとは何か - エンジニア新卒研修 スライド公開 | Mori Atsushi | SpeakerDeck
129あとで/870users ななななんと!AWS認定の模擬試験が無料になりました!! | DevelopersIO
129あとで/907users 役所はあえて教えない…「年金」を「毎年30万円以上多くもらう人たち」の凄テク(加茂 直美) @moneygendai
128あとで/658users 50分で学ぶアルゴリズム / Algorithms in 50 minutes | E869120 | SpeakerDeck
127あとで/683users Kubernetesをゲーム感覚で腕試しできるサイト「Game of PODs」で遊ばないと年を越せない・2021冬 | ASCII×FIXER
127あとで/742users アルゴリズムの世界地図 - Qiita
127あとで/1404users やばいと思ったらすぐ逃げる。ある研究室のスライドに「人生で大事な7つのこと」が書かれていると話題に。 | 澤木香織 | Huffpost
127あとで/782users CTOが選ぶ、エンジニアのみなさんに個人的に読んでほしい本|藤村|note
ついにはてな社が公式に[あとで読む]ランキングを公表した。2021年の振り返りができる。指標としてブクマ数に占める[あとで読む]の率を重視している。これにも[あとで読む]がたくさん付いて14位にランクインした。
リクルートにおける VDI の導入、運用、コロナ対応、そして今後の ICT 環境を紹介する連載。
最終回は、現在取り組んでいる VDI と FAT PC のマルチ環境についてお伝えする。
石光直樹,リクルート(2021 年 06 月 04 日)
28 →目次に戻る
ただし、そうしたユーザーに対して環境が変わることについてきちんと説明しないと、混乱につながってしまいま
す。そこで、「なぜこのような環境に切り替えることに至ったのか」や、目的、狙いについてプロジェクト内で改め
て議論しました。ユーザーに対して納得感ある形で社内説明資料などをまとめて、各部署の主要なユーザーに向
けて情報を発信していきました。
今後の移行時には、さらに分かりやすい資料の共有や移行マニュアルの整備などを行い、社内広報の体制も整
えていきたいと考えています。
マルチ環境の実現は簡単なことではありません。特に FAT PC の環境をどう作るのかについては、時間をかけ
て検討しました。まずは、VDI 導入により大幅に解消された “3 つの課題 ”、すなわち「セキュリティの向上」「PC
管理コストの削減」「働き方変革への貢献」の対応策を FAT PC でどのように実現するか。これが次の課題です。
「セキュリティの向上」については、高セキュリティ業務にはセキュア VDI を提供し続け、FAT PC に対しては従
来よりもセキュリティを強固にすることにして、この課題をクリアしました。
続いて「PC 管理コストの削減」では先述の通り、VDI 化によって大きなメリットを得られた部分でした。例え
ば、夜間にパッチを当てたりできるのは、システム管理担当者からすると非常にメリットになります。ところが、FAT
PC に切り替えると、このメリットは享受できなくなってしまうことから、VDI 導入時に刷新した PC 管理システム
を FAT PC にも導入することで一定の解決を図るのに至りました。VDI の導入前に使っていた “ お手製 ” の PC
管理システムでは、パッチ当てや OS 更新などが大変でしたが、最新の PC 管理システムを導入することで、かな
り容易になっていたからです。とはいえ、VDI の管理性には劣ります。この点は、中長期視点でのより良い環境を
目指すために、優先度を下げた部分といえます。
そして「働き方変革への貢献」については、先述の通り、昨今の状況を踏まえると、ビデオ会議をより活用で
きる FAT PC の方がメリットを引き出せるのではないかと考えました。ただし、FAT PC に切り替えることで、い
ままでとはネットワークの流れ方が変わってきます。VDI では、データセンターと端末の間でやりとりされるのは
VDI 画面のデータが中心でしたが、FAT PC ではさまざまな実データがやりとりされることになります。また、社
外などから社内に VPN 接続をする必要があり、その部分がボトルネックになりがちです。その問題に対しては、
ネットワークを再検討することで解決を図ることにしました。われわれの社内ネットワークは VDI に最適化されて
いたので、FAT PC の増加に合わせて拠点のネットワークを増強したり、VPN を増強したりすることを検討しま
した。これにより、働き方変革で求められていたテレワークの要件に対しても十分応えることができると考えてい
たのです。
29 →目次に戻る
しかしながら、この方針は大きく変更を余儀なくされることになります。その理由は 2 つあります。1 つ目はコ
社内ネットワークの再検討はコロナ禍の影響を強く受けることになりました。在宅勤務の方針が示されたこと
で、社内からの接続が減る一方、リモート接続が増え、社内のネットワークトラフィックの在り方が大きく変わって
しまったからです。コロナ禍が続く中で、そしてアフターコロナでそういった状況がどうなるのかについては予測が
難しく悩みました。単純に拠点のネットワーク、特に WAN を増強したとして、使われなくなるなら投資が無駄に
なってしまいます。また、ネットワークにおいては今後のトレンドとして「ゼロトラストネットワーク」が注目されて
きています。おそらく、われわれの目指す「クラウド&マルチデバイス環境」を支えるネットワークは「ゼロトラス
トネットワーク」になることでしょう。
では、いま「ゼロトラストネットワーク」のようなネットワークを入れるべきなのか。それともいまは暫定構成に
して将来的に「ゼロトラストネットワーク」に移行できるようにするのか――。
コロナ禍で勤務の環境が急速に変わってきていることも踏まえて、この点を検討しなければならなくなりました。
いまもまさに検討しているところで、いまだに完全な結論は出ていませんが、現時点では PC 環境と同じく、将来
的には「ゼロトラストネットワーク」に移行できるように、いまのネットワーク構成を考えるべきと思っています。
変化に対応して、かつ自ら変化を引き起こす
さらに、FAT PC 導入においては大きな変化があります。それは「SAC」(Semi-Annual Channel、半期チャ
ネル)の導入です。
VDI 環境においても「Windows 10」の導入は完了していましたが、「LTSB」(Long Term Servicing Branch※)
を導入していました。頻繁な更新を望まないユーザー向けに作られた、機能更新がない固定的な Windows 10 のモ
デルです。これに永続ライセンス版の「Microsoft Office」を組み合わせて利用していました。
※現在の名称は、「LTSC」(Long Term Servicing Channel、長期サービスチャネル)
これは、「レガシーアプリが存在するので、機能更新がない OS の方がいい」と思っての選択でした。しかし、機
能が更新されないので、OS や Office の最新機能が利用できないなど、将来的には「Microsoft 365」への接続
も制限されるような状況でした。
30 →目次に戻る
他方、SAC なら OS や Office が常に最新の状態になります。そのため、半期あるいは 1 年に 1 回程度のペー
スで機能が大きく更新されます。IT 部門としては、機能更新時に社内アプリケーションの動作確認などをする必
要があり、PC 管理タスクが増えてしまうことになります。PC 運用コストの増大につながり得るので、VDI から
FAT PC に切り替える際の検討ポイントの一つでもありました。しかし、ここでもわれわれは中長期視点を大事に
しました。
今後の「クラウド&マルチデバイス環境」においては、環境が常に最新になる世界が普通になるでしょう。いま
のスマートフォンを見てもそうですが、OS はどんどん更新されて、次々と新たな機能やサービスが利用可能にな
るのがむしろ普通であり、その波が PC の世界にも到来しているのです。PC 運用コストが上がったとしても、わ
れわれもこの波に乗って、ユーザーに対しても新機能やサービスを次々に提供していき、より良く業務を行っても
らえるようになればすてきだなと思いました。
そこで、VDI から FAT PC への切り替えに際して、OS のモデルも LTSB(LTSC)から SAC に変更すること
にしました。PC が最新に変わっていくSAC のような世の中の変化に対応しながら、われわれの環境においても
変化を引き起こして業務を変えることができればと思い、現在、導入を進めています。
VDI 基盤の抜本的な刷新
ここまでは大多数のユーザーが利用することになる FAT PC のことを中心に述べてきましたが、セキュア VDI と
特定用途 VDI として利用する VDI 基盤のリプレースも大きな仕事です。
VDI 基盤リプレースにおいてもいままでの構成を踏襲せず、一からあるべき姿を検討することにしました。まず
検討したのはクラウドの導入です。将来「クラウド&マルチデバイス環境」になれば、VDI 自体もクラウドのサー
ビスの一つという位置付けになるだろうと考え、クラウドでの VDI 利用を検討しました。
しかし、残念ながら今回クラウド VDI の採用には至りませんでした。われわれの試算ではオンプレミスに比べて
コストが見合わなかった点と、管理機能がまだまだのように思えた点が見送りの理由でした。クラウドはますます
発展する領域なので、今後は状況が変わるかもしれません。われわれも引き続き状況を観察し、一部の環境には
クラウドをトライアル的に導入してみることも視野に入れて、現在、検討しています。
当面の方針としてオンプレミスの VDI を構築することにしましたが、いままでの構成をそのまま踏襲するような
ことはしませんでした。必要としたのは、運用性やコスト、拡張性に優れたアーキテクチャでした。
31 →目次に戻る
議論、検討を重ね、さらに比較、検討した上で、われわれは HCI(Hyper Converged Infrastructure)構成
を選びました。HCI はサーバ中心のアーキテクチャで、SAN(Storage Area Network)スイッチやストレージ
を省くことができ、構成がシンプルになり、運用性やコストにメリットがある他、リソース拡張はサーバを追加する
だけでよいので、拡張性にも優れています。われわれが望んでいた点を満たすアーキテクチャと評価しました。
いままでは「サーバ+ネットワーク+ストレージ」のいわゆる「3Tier」構成で安定運用できていたので、これを
変えるのは大きなチャレンジでした。とはいえ、チャレンジしないことには運用性もコストも拡張性も勝ち取れませ
ん。「新たなことに挑戦するのが、われわれのエンジニアリングの方針だ」と考え、HCI 構成を選びました。
加えて、VDI 基盤のデータセンターのネットワークを SDN(Software Defined Network)に切り替える決断
男女・多目的以上のトイレとかうんと後回しでいいわそんなもん。トイレに入れて、個室を選択することもでき、排泄ができる。それ以上を世に求めんな贅沢なんだよ。
そんなことよりアレルギー問題の方がよっぽど切実だろ。衣・食・住の1つだぞ?アレルギーがあることによる飲食店の選択肢低下こそ人権問題である。
アレルギーのある人間は、人間関係の構築にもほかの人にはないハードルが存在する。主義主張でなく肉体の都合でだ。「あいつ呼ぶと行きたいとこ行けないからやめようぜ」と。家族なんて一生それに付き合うわけだ。フードデリバリーもままならない。
以下のせめてレベル2まではあらゆる飲食店(デリバリー含む)に義務化しろ。それ以上は「より良い世界」の指標で、まだかまわない。
FF、ドラクエの古き良き「思い出」を超えろ――絶滅危機を乗り越え、再注目されるドット絵
14
任天堂の家庭用ゲーム機「ファミリーコンピュータ」の誕生から38年。16×16の四角形の集合体にすぎないドット絵の「マリオ」は世界の人々をとりこにした。ゲームは進化して実際の映像に近づく中で、衰退したはずのドット絵が復興し、若い世代にも広がっている。その魅力とは。(取材・文:河村鳴紘/Yahoo!ニュース オリジナル 特集編集部)
今年5月、「ドラゴンクエスト3」のリメイク(対応ハード未定)が発表された。公開されたティザームービーにはキラキラと光を反射する水面や、住人の息づかいが感じられる町の灯りと影の世界が描写されている。
こうした臨場感あふれる表現を可能にしたのが「HD-2D」だ。四角い点を枡目状に並べて表現するレトロなドット絵に3DCGを融合させる手法で、懐かしさと新しさが同居する不思議な魅力がある。
「ドットに関しては『今の時代にこれか』というユーザーの声ももちろんあるんです」
そう語るのは株式会社スクウェア・エニックスのプロデューサー・高橋真志さん。
高橋さんの制作チームでは「狭くともちゃんとユーザーに刺さるものを作ろう」というコンセプトのもと、ドット絵ベースのゲーム制作を開始した。
初めて「HD-2D」を採用したタイトルは、2018年にリリースした「オクトパストラベラー」だ。同作では試行錯誤の末に「HD-2D」というアプローチを見いだした。
「『ファイナルファンタジー5』や『6』のようなドット絵を目指そうとやって……できた試作版の感想が、いい意味でいうと “懐かしいね”、悪い意味でいうと“古臭い”というものでした」
明らかに試作版の方が昔のものよりきれいな絵なのに、なぜか「劣る」ように思えてしまったのだ。
「それは過去の思い出が美化されてしまう『思い出補正』のせいでした。私は初めてスーパーファミコンでプレーしたのが『ファイナルファンタジー5』なのですが、当時の体験とともにドット絵が原風景として強く残っているんです。ユーザーさんも同様に感じ取ってしまうはずだから、その分の下駄を何で履かせるか考えた先に3Dに行き着きました」
FF、ドラクエの古き良き「思い出」を超えろ――絶滅危機を乗り越え、再注目されるドット絵
14
任天堂の家庭用ゲーム機「ファミリーコンピュータ」の誕生から38年。16×16の四角形の集合体にすぎないドット絵の「マリオ」は世界の人々をとりこにした。ゲームは進化して実際の映像に近づく中で、衰退したはずのドット絵が復興し、若い世代にも広がっている。その魅力とは。(取材・文:河村鳴紘/Yahoo!ニュース オリジナル 特集編集部)
今年5月、「ドラゴンクエスト3」のリメイク(対応ハード未定)が発表された。公開されたティザームービーにはキラキラと光を反射する水面や、住人の息づかいが感じられる町の灯りと影の世界が描写されている。
こうした臨場感あふれる表現を可能にしたのが「HD-2D」だ。四角い点を枡目状に並べて表現するレトロなドット絵に3DCGを融合させる手法で、懐かしさと新しさが同居する不思議な魅力がある。
「ドットに関しては『今の時代にこれか』というユーザーの声ももちろんあるんです」
そう語るのは株式会社スクウェア・エニックスのプロデューサー・高橋真志さん。
高橋さんの制作チームでは「狭くともちゃんとユーザーに刺さるものを作ろう」というコンセプトのもと、ドット絵ベースのゲーム制作を開始した。
初めて「HD-2D」を採用したタイトルは、2018年にリリースした「オクトパストラベラー」だ。同作では試行錯誤の末に「HD-2D」というアプローチを見いだした。
「『ファイナルファンタジー5』や『6』のようなドット絵を目指そうとやって……できた試作版の感想が、いい意味でいうと “懐かしいね”、悪い意味でいうと“古臭い”というものでした」
明らかに試作版の方が昔のものよりきれいな絵なのに、なぜか「劣る」ように思えてしまったのだ。
「それは過去の思い出が美化されてしまう『思い出補正』のせいでした。私は初めてスーパーファミコンでプレーしたのが『ファイナルファンタジー5』なのですが、当時の体験とともにドット絵が原風景として強く残っているんです。ユーザーさんも同様に感じ取ってしまうはずだから、その分の下駄を何で履かせるか考えた先に3Dに行き着きました」
再び活況を取り戻したドット絵ゲームだが、2006年ごろになると、モバイルゲームのトレンドはMobageやGREEなどのプラットフォームが提供する「美麗カードゲーム」へと移っていく。小林さんも現場から退きディレクター職に軸足を置いていた。またもドット離れの時代の到来か……。そんな諦念を払拭したのが、2013年にエイリムから出たスマートフォンアプリゲーム「ブレイブ フロンティア」だ。ドット絵ベースRPGにスマートフォンのタップ操作を掛け合わせたゲーム性が90年代のゲームファンを魅了。全世界で合計3800万ダウンロードを記録する大ヒットとなった。
勢いに乗るエイリムにいた元同僚から声がかかり、小林さんも再びドッターとして腕を振るうこととなった。現場では、ユーザーのダイレクトな反応にも触れることができた。
「『やっぱりドット絵好きです』っていう声が、具体的に上がるようになったんです。過去の産物とかではなく、ドット絵はドット絵でいいよね、って認識できました」
さらに大きなうねりをもたらしたのは海外のインディーズゲームだった。
2011年に正式リリースされた「マインクラフト」はドットテイストの3Dブロックによって自由に世界を構築するゲーム。複雑な造形物を描くにはドット絵の素養が必然的に要求される。さまざまなプラットフォームに配信され2億本以上売り上げるなど、一大ブームを巻き起こした。
(Christian Petersen/Getty Images News/ゲッティイメージズ)
完全ドットベースのインディーズゲームでは2015年リリースの「Undertale」もその代表格だ。アメリカのゲームクリエイターであるトビー・フォックス氏の個人開発で、100万本以上の売り上げを誇る。モンスターのすむ地底世界を舞台に、子どもが地上に戻るための冒険をする……という内容だ。ゲーム好きをうならせるストーリーと個人開発とは思えぬほどの異常な細部へのこだわりが熱狂的なファンを獲得し、口コミで広がっていった。
CGに比べて制作コストの低いドット絵はインディーズゲームクリエイターに好まれた。しかし、あくまでクリエイターの趣味の領域にとどまり、それ以上の広がりにはつながりにくい一面もあった。そこにSteam等のゲーム配信プラットフォームや、Twitter、YouTubeといったSNSの普及もあいまって多くの人の目に触れ、ドット絵の灯が紡がれたといえる。特にマインクラフトに関してはティーン層にも広くリーチし、新たなドット絵ユーザーの拡大に大きく寄与している。
テレビゲームからモバイルゲームへと、時代に応じて活躍の場を広げてきたドット絵。
近年はゲームの世界だけでなく、「ピクセルアート」のように、ドット絵をゲーム以外の文脈と接続しながら新たな魅力を発信する試みもある。
シブヤピクセルアート プロデューサー 小野氏(左)・代表 坂口氏(右)
東京・渋谷で2017年から毎年展開されるアートイベント「SHIBUYA PIXEL ART」。
「近年、街がDX化される中で、文化的なものを組み込みたいと考えた」
「ゲーム文脈から拡張されたピクセルアートを、多様な形で展開できる場所として渋谷を選んだ」
現在は50人以上のクリエイターが国内外から参加し、大手企業による協賛やアーティスト・ゆずとのコラボレーションなど盛り上がりを見せている。
参加クリエイターのうち、3割が10~20代と若い。彼らにはドット絵のシンプルな技法が新鮮に映るという。また、四角形の集合体で構成するドット絵に対して縦横ではなく「斜め」の線を使い物議を醸すなど、“常識”に挑む斬新なアプローチが光る。
バウエル・ジゼル・愛華さん
「SHIBUYA PIXEL ART 2021」で優秀賞を受賞した高校生モデルのバウエル・ジゼル・愛華さんもその一人。ドット絵をプログラムで動かすYouTubeの企画がきっかけで、ドット絵を描くようになった。「少ないピクセルの中でどれだけきれいに描けるか、というのが楽しい」と話す。下書きもせず何となくテーマを決め、タブレットとペンでバランス良くモノを配置しながら作りあげてしまう。
「SHIBUYA PIXEL ART 2021」で優秀賞を受賞したバウエルさんの作品
「粗いドットのデジタルの雰囲気が逆に新しい」とバウエルさん。ドット絵は新たなファン・クリエイターを取り込みながら、活躍の場を広げている。
新世代も取り込みながら進化を続けるドット絵。制作中の「ドラゴンクエスト3 HD-2D リメイク」にも、新たな可能性を示す仕上がりを期待したい。