「ロードバランサー」を含む日記 RSS

はてなキーワード: ロードバランサーとは

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-10

現代日本で子を持つことって道楽なんだな

ワーママになったはいいが、マジで時間が足りない。自分をもう1人ほしい。

子育てもなるべく傍にいてあげたい、

でも仕事はしたいし趣味もしたい。

圧倒的に時間と体力が足りなすぎる。

仕事趣味もない人がいたら、その人の身体を乗っ取ってロードバランサーをかませて負荷分散したい。

冷静に考えて専業主婦の人がやってることをやりつつ、一人前とは言えないかもしれないが仕事フルタイムでやるって無理があるんだな。

保育園はあるけど保育料がそこそこかかるし、当然ながら仕事してる時間しか預かってもらえないし。

子が体調を崩したり何か子の用事がある時は突発的に仕事ができなくなって、チームの足を引っ張る。

仕事量は多いままだから、子を寝かしつけた後に睡眠を削って仕事に戻る。

たぶんこんなの客観的に見て全部ワーママならあたりまえのことなんだろうけど、自分がなってみて初めて、これきついなって思わされた。

というか、核家族子育てしながら働くということが、未だに周りに負担をかけるか本人が無理することでしかなしえない状態だ。

年代でも子を持たない人達が増えて、その人たちの生活優雅で羨ましく、妬ましく見えるのもしんどい

アルコールなんてずっと飲んでいないし、綺麗な服も着ず、イベント事や映画、お洒落な店なんかもそうそう行けない。

金銭的なプラスマイナスとかは気にしていないが、結局子が可愛いのは可愛いし、道楽のつもりで楽しむしかないのかもしれないな、と思う。

いつか脳に繋いで自分のやりたいことを負荷分散できる仕組みができますように。

2021-05-20

anond:20210520100801

Webサーバは、プロキシとかキャッシュとかロードバランサーとか色んな役割を持てるので、役割に応じてapacheでもnginxでも何段にも重ねることはある

2021-02-20

anond:20210220112831

国民教養として必要情報処理法律で現状教えられてないもの、って具体的にはどういうのを想定してるの?

専門家じゃないからわからないよ!

素人所感だと、

情報処理は、「関数」と「レイヤー構造」かな!

関数は、「インプット」「アウトプット」「処理」の要素から成立していることとかね!

関数理解すると、「ソフトウェア関数の集合にすぎないこと」「機械学習所詮関数一種にすぎない」のように、「得体のしれない便利なもの」という理解から進めるからね!

関数理解できれば、Excelはもちろん、熱量計算とか言語分析とか各専門分野で利用できるからね!

プログラミングを教えるべき!」ってのは「関数理解させるべき!」って意味だと思うんだよね。

言語仕様アルゴリズムは必ずしも必要とは思わないよ!

次に「レイヤー構造」ね!

例えば「ソフトウエアにおけるアプリケーション層データ層…」とか「ハードウェアにおけるサーバデータベース、ロードバランサー…」とか「ネットワークにおける物理層セッション層…」とかね!

レイヤー構造理解すると、全体と部分の関係がはっきりして、各要素の理解が進むからね!

レイヤー構造理解できれば、情報処理に限らず、ものごとを整理して理解することに役立つよね!

法律は、「法」と「契約」かな!

法は、各法の目的理解かな!何のために存在して、法改正によってどう影響があるか理解できるからね!

各条文を細かに理解する必要はないけれど、条文の読み方は修得させたいよね!

契約は、騙されないためにだね!

2021-02-11

anond:20210211125240

ロードバランサーかましいるから、ログのものは、難しくないが

ロードバランサーかましているがゆえに、完結障害データロスしやす

まり

高速性ではなく高信頼性が難しいというのが、高速ロギングという言葉で誤解を生んでいるよな

 

高速ロギングとは速度の技術ではなく、その速度で高信頼性を出すための技術のこと

2021-02-03

CloudFrontと相性が悪いため

しばらく

こっちをかしてくれ

 

やはり年単位で調整を繰り返しているが

ブログコメント欄

相性が悪いな

コメントスパムもあるから

PHP直撃にすると、こんどはクローラーに潰される

急激な1日だけの大手サイトリンク対応するとCDNになって、コメント対応できない

 

調整がめんどくさいことこの上ない

バランスが難しいね

どうしてもコメントを開けようとすると

ロードバランサー入れてPHPマルチにしないと負荷に耐えられないが

わずか1年で1日未満のあめに、のこりをずっとあげておけはたしかに無謀

Lambda pressでリミッター入れる以外の方法にたどり着けない

2021-01-30

anond:20210130105634

サーバーを増やしてくれれば、それだけで10倍までは性能が上がるから、弊社はは大丈夫。100倍はちょっと確認がいるけど

10倍まではいける ロードバランサーはうちのちーむではないからしらんが1台1台はそうせっけいしてある。

それ以上となると、いわゆるNFSへの書き込みをさげてやらないと、難しいとは思うがさすがに、そこまではいきすぎだから発注してくれ

トラヒックバーストで10倍までは絶えられれば普通責任分界点を超えている

2021-01-29

とりあえず、報告

Amazon AWSEC2ロードバランサーマルチAZ

RDSはシングルAZ対応したが

EC2はしなかったもよう。

何の意味があるんだ・・・どう考えても専門家がやってねぇ

マルチ構成がなんだかわから設計している

へたすると設計のものが流用(知財権利を買ってない) ちがうとはおもうが、各位確認されたし 通報はあとでまとめて

わかりやすい例を1つだけ

2020-08-02

数千倍まではロードバランサーチームがちゃんバランシングしてくれればたえるはず で 数千倍にたえられれば 国内国民が一人数台のパソコンをつかっても たぶん耐えられる設計にはなってるはず

そのままサーバの台数を倍にして、あとはロードバランサーチームがなんとかする

2020-05-23

EC21台 RDS1台の最小構成だけど ロードバランサー最初から入れておいたほうが楽かもね

ロードバランサー1台 EC2 1台 RDS1台 VPC2個 サブネット2個ぐらいかスタートするのがいいか

テストときだけEC2 2台にして 普段は1台で とまったらとまったでいい

2017-08-29

ロードバランサー

今日ね、負荷分散をしようと思ってロードバランサーを立てたんですよ。

で、ドメインDNSレコードでAAAA値を追加しようとした時に気がついたんですが

ロードバランサーipv6が無かったんですよ。

で、ヘルプデスクに聞いてみたわさ。ほいたらすったらもんねー!ってさ。

あいまんこったねー!ってさ。

グモさん、そりゃねーんじゃねえべか?ipv4はもうすぐ枯渇するべよ?

2017-05-27

はっぴょんの件

huluブランド継続するのにドメイン変えるって悪手だなーと思っていたんだけど、hulu側のシステム日テレ側が(技術的か法的かわからないけど)全く触ることができなくて、ああいリニューアルになったんじゃないかなと思った。

ドメイン同じで新旧のシステムを振り分けるなら、前面にロードバランサー置いてUA見て振り分ける、とかになると思うけどその辺のシステムが触れない。

happyon.hulu.jpというサブドメインをつくって、そっちでアクセス受けて新システムにに振り分ける、ということもできそうだけど、DNSも触れない。

みたいな

2017-03-05

コメ率の低いはてブエントリ英語エロか?

http://anond.hatelabo.jp/20170305115905増田以外のホットエントリで見ると。

2017年2月コメント率の低いホットエントリ

コメントタイトルコメント数/ブクマブクマページ
0.0%Python3.6 から追加された文法機能 - Qiita0/96b.hatena.ne.jp/entry/324476241
0.8%文章ベクトル化して類似文章の検索 - Qiita2/245b.hatena.ne.jp/entry/324662835
1.0%[wip] 会社サーバサイドエンジニアにReactとかReduxのことを説明する資料 - Qiit1/97b.hatena.ne.jp/entry/319535213
1.1%機械学習ディープラーニングの入門者向けコンテンツまとめ - Qiita1/94b.hatena.ne.jp/entry/321793279
1.9%Web制作時の概算費用と想定納品日を簡単に計算する票をつくってみた – のんびりデザインしているよう7/375b.hatena.ne.jp/entry/320010979
2.0%最近見かけるレイアウト・ナビゲーション・スライダーフォームなどがどうやって実装されているのかのまと7/344b.hatena.ne.jp/entry/322198623
2.2%フロントエンド知らない私のwebpack入門 その1 - Qiita4/186b.hatena.ne.jp/entry/319233247
2.3%フルマネージドのSaaSクラウドデータベースサービスdashDBの活用スタイルとは ~手間いら5/216b.hatena.ne.jp/entry/323891713
2.4%Pythonをやるときに参考になりそうな情報 - のんびりSEの議事録19/807b.hatena.ne.jp/entry/322300431
2.5%React基礎 · GitBook17/681b.hatena.ne.jp/entry/321494522
2.7%開発効率を上げるテスト設計 // Speaker Deck5/183b.hatena.ne.jp/entry/323584734
2.8%畳み込みニューラルネットワーク可視化 - 人工知能に関する断創録3/108b.hatena.ne.jp/entry/322431100
2.8%グランブルーファンタジーを支えるインフラ技術 // Speaker Deck10/359b.hatena.ne.jp/entry/324611754
2.9%仮想DOMの内部の動き | プログラミング | POSTD6/206b.hatena.ne.jp/entry/321289144
3.0%金融データPythonでの扱い方 - 今日も窓辺でプログラム16/527b.hatena.ne.jp/entry/322842311
3.1%Python Jupyter notebookでpandasを使いCSVを読み込みグラフを描画してp5/162b.hatena.ne.jp/entry/321556884
3.1%React Redux Real World Examples 〜先人から学ぶReact Redux9/290b.hatena.ne.jp/entry/323749846
3.2%Awesome Python:素晴らしい Python フレームワークライブラリソフトウェア・リ15/472b.hatena.ne.jp/entry/319013267
3.2%履歴書志望動機|最速で書く方法と受かる書き方14/433b.hatena.ne.jp/entry/279613157
3.4%今日からはじめるGitHub初心者がGitをインストールして、プルリクできるようになるまでを解38/1128b.hatena.ne.jp/entry/318690305
3.4%スケーラブル GCP アーキテクチャ6/178b.hatena.ne.jp/entry/322723492
3.5%アーキテクチャから新しい! 初めてのエディタには、21世紀生まれの「Atom」がおすすめ【続・若手エ11/311b.hatena.ne.jp/entry/322534650
3.5%フロントエンドの基礎知識 // Speaker Deck15/423b.hatena.ne.jp/entry/322749937
3.7%ロードバランサー再入門 | ツチノコブログ26/704b.hatena.ne.jp/entry/323163487
3.7%APIサーバを立てるためのCORS設定決定版 - Qiita5/134b.hatena.ne.jp/entry/321742626
3.8%画像】こんなのソフマップじゃないwwwwwwwwwwwwww|ラビット速報5/131b.hatena.ne.jp/entry/321219627
4.0%動画あり】人志松本のゾッとする話のあるある探検隊の話怖すぎwwwwww | 2ちゃんねるスレッド10/252b.hatena.ne.jp/entry/319507149
4.0%翻訳2017年展望: pandas, Arrow, Feather, Parquet, Spa7/176b.hatena.ne.jp/entry/324411617
4.2%【たまに行くよ!って人向け】いつもと少しちがう東京ディズニーシーデートにするための5つの方法 @ja3/72b.hatena.ne.jp/entry/321496344
4.3%高速なシステムを作る方法 // Speaker Deck9/211b.hatena.ne.jp/entry/283448858
4.3%処分・廃棄にお金は要らない!?パソコン無料引取してくれる業者一覧7/162b.hatena.ne.jp/entry/320803373
4.3%タデサプリを支えるデータ分析基盤 ~設計の勘所と利活用事例~3/69b.hatena.ne.jp/entry/322583838
4.4%「Front-End Developer Handbook 2017」がGitBookで無償公開。フ24/542b.hatena.ne.jp/entry/318947145
4.6%デブサミ2017「DeNAの機械学習基盤と分析基盤」講演メモ #devsumi - 元RX-7乗りの7/152b.hatena.ne.jp/entry/322562611
4.6%大量の要素を高速に表示するためのバーチャルレンダリング入門 / Virtual Rendering 6/130b.hatena.ne.jp/entry/323604383
4.7%MySQLアンチパターン22/473b.hatena.ne.jp/entry/319218778
4.7%5年間コードを書き続けたエンジニアが、新人に読んでもらいたい11冊+αを紹介する - エンジニアHu47/1006b.hatena.ne.jp/entry/313934939
4.7%グーグル社員も長友選手も行う集中力を高める方法 - 自分で学ぶ心理学20/427b.hatena.ne.jp/entry/322090614
4.8%例の機械学習コースが良いらしいと知りながらも2年間スルーし続けたがやはり良かったという話 - Qii68/1418b.hatena.ne.jp/entry/321403591
4.9%NoSQL を使用する場合と SQL を使用する場合Microsoft Docs28/577b.hatena.ne.jp/entry/322834020
4.9%Awesome Selenium : 素晴しい Selenium ライブラリの数々 - Qiita5/102b.hatena.ne.jp/entry/321629987
4.9%誰でもできる、プレゼンが劇的にうまくなる基本テクニック - 科学非科学迷宮77/1557b.hatena.ne.jp/entry/318913434
5.0%脆弱性発見者が注目する近年のWeb技術 // Speaker Deck24/481b.hatena.ne.jp/entry/319516657
5.1%たった3つのコトで仕事が楽になる!「できる上司の会議」がマジで真似したい | CuRAZY [クレイ7/138b.hatena.ne.jp/entry/322534334
5.1%日経電子版を支える基盤API // Speaker Deck13/256b.hatena.ne.jp/entry/319592914
5.1%30歳から始める数学 - Shoyan blog50/982b.hatena.ne.jp/entry/323617832
5.1%インフラチームと開発チームの垣根をなくすためにAWSのCI環境を構築した話 - VOYAGE GRO20/392b.hatena.ne.jp/entry/323171376
5.1%『How to Get Startup Ideas』 - いかスタートアップアイデアを得るか -17/333b.hatena.ne.jp/entry/324384439
5.1%無料ウェブサイトブログに使える写真を検索可能な28サービスまとめ - GIGAZINE18/350b.hatena.ne.jp/entry/323600897
5.2%内向的な人のための面接ガイド - GIGAZINE14/271b.hatena.ne.jp/entry/322036523

Pythonデータベース関連が目立つ。コメント無しで96ブクマに達するPythonさん凄い。マウンティング心?を刺激しないのだろうか。炎上したくない人はインデントに気をつけながらオブジェクト指向で書くといい。

2017年2月コメント率の高いホットエントリ

コメントタイトルコメント数/ブクマブクマページ
74.5%はてブ要望「返信出来るようにして欲しい」 - interact114/153b.hatena.ne.jp/entry/319990286
73.5%あなた朱雀とか白虎とか四神を覚えたキッカケは何?」という質問に対し世代がバレそうになる人々→「幽319/434b.hatena.ne.jp/entry/322198765
67.8%内海 聡さんのツイート: "あなた甲殻類アレルギーだった場合あなたの心は殻に閉じこもっている可449/662b.hatena.ne.jp/entry/318821783
67.4%日米首脳会談 首相は「ドラえもん」のスネ夫になった!民進党野田幹事長が批判 (産経新聞) - Ya95/141b.hatena.ne.jp/entry/321930776
65.7%いい記事書けばブクマつくとか嘘っぱち!こんな嘘がまかり通るはてな界に物申すっ! - ゆるくいきていく260/396b.hatena.ne.jp/entry/323206934
65.5%痛いニュース(ノ∀`) : 梅沢富美男(66)、老害判定に怒り 「日本は俺達が作ったんだぞ!」 - 190/290b.hatena.ne.jp/entry/322785094
65.5%茶碗に米粒を残した状態で「完食」する人は完全悪ではないけど相容れられない、という話に意見続々 - T413/631b.hatena.ne.jp/entry/321479096
64.6%けものフレンズを視聴1分30秒で挫折。 - 自由ネコ122/189b.hatena.ne.jp/entry/321589678
63.7%けものフレンズコスプレ批判に対する異論まとめ - Togetterまとめ228/358b.hatena.ne.jp/entry/323622485
63.6%レジでバレる!二流の人の超ヤバい3欠点』という東洋経済記事を読んで。クレジットカードイメージ119/187b.hatena.ne.jp/entry/323599229
63.5%痛いニュース(ノ∀`) : 日本在住のイスラム教徒の子どもがハラール対応給食に苦慮→学校側に配慮290/457b.hatena.ne.jp/entry/321128745
63.0%あざなわさんの炎上はてな村権威のなさ - メロンダウト133/211b.hatena.ne.jp/entry/323813866
62.7%プレミアムフライデーって何でこんなに叩かれてるんだろう? - シャイニングマンの「勇気を君に」126/201b.hatena.ne.jp/entry/324113658
62.5%飯田譲治さんのツイート: "日本が悪い日本が悪いって、民間人は殺さないってルール破って、原爆落として65/104b.hatena.ne.jp/entry/321434534
62.4%偏差値40の大学日本必要なのか?子供を焼き殺す大学補助金は不要 - カキカエブログ166/266b.hatena.ne.jp/entry/318786744
62.2%坂上忍 清水富美加の月給5万円は正当「僕らの時もそうだった」 (デイリースポーツ) - Yahoo!237/381b.hatena.ne.jp/entry/321888913
61.9%清水富美加17日著書出版「全部、言っちゃうね。」 - 芸能 : 日刊スポーツ73/118b.hatena.ne.jp/entry/322431771
61.5%警視庁捜査1課長が竹刀で23歳美人記者ボコボコ (文春オンライン) - Yahoo!ニュース415/675b.hatena.ne.jp/entry/322218394
60.7%ゴルフに興じる首相、誇れない」民進・蓮舫氏:朝日新聞デジタル136/224b.hatena.ne.jp/entry/321608217
60.6%金があるのに、理屈をつけてコンテンツに金を落とさない」連中について - うらがみらいぶらり243/401b.hatena.ne.jp/entry/321324226
60.6%痛いニュース(ノ∀`) : 中学校で「やばい」という言葉を使用禁止に 若い世代意味多様化 - ラ132/218b.hatena.ne.jp/entry/324642052
60.3%受動喫煙対策東京だけでやれ」 自民党内で反対論噴出:朝日新聞デジタル241/400b.hatena.ne.jp/entry/321316384
60.1%娘の卒業式用の服を買いに行ったら驚愕した - コバろぐ92/153b.hatena.ne.jp/entry/321299915
60.1%「洗剤いらず」スポンジで教頭などが児童の体こすりけがNHKニュース215/358b.hatena.ne.jp/entry/322584234
60.0%松井一郎さんのツイート: "長谷川さんが、ブログで伝えたかったのは、健康であるための自己管理重要201/335b.hatena.ne.jp/entry/320414066

2013-11-09

Webサーバが3台って

今日、同僚と2人で飲みに行った。

相手はソフトウェア業界で働く業界6年目の男。

私は業界11年目だが、ともに中途入社で彼とは同時期に転職してきた。

だけど、彼の技術レベルが低すぎて泣ける。

Webサーバが3台あるシステムがあるんだけど、

彼は3台ある意味が分かっていなければ

ロードバランサーという言葉も知らない。

「何でWebサーバが3台あると思う?」

「1号機がリクエストを受けて、2号機、3号機と順にデータコピーしてるんじゃないんですか?」

もうほんと謎。


本人いわくサーバはあまり経験いから、ってことだけど、そのレベルを超えてる。

頭いたいわ。

2008-10-13

http://anond.hatelabo.jp/20081013123012

Web系は動けばよいで、セキュリティー忘れて、大問題になった、例が過去どれだけあるかを説明しないといけないのは、とっても手間だよね。

あと、Web系でもベンチマークは必要。マシン2台と1台の差はあまりないかもしれないけど、200台と100台の差は結構あるし。

電気代や、サーバーラック代、メンテナンス費用、などのランニングコストに効いてくる。

ロードバランサーも高い物を検討しないといけなくなってくる。

システムから見れば、Web系でもベンチマークしてトータルソリューションのコストダウンすることは非常に重要

というのを説明しないと行けないのは、とっても手間だよね。

わかります。

2008-03-19

自慢の知識が役に立つと思ったのに

ネトゲ雑談を聞きに行ったら、

突然、システマティックな話題に移り、

それについて行けない俺は涙目。

Lv.○○までは、あの武器スライム叩いとけばパフォーマンスぐっどよーみたいな話ならついて行けるのに。

TCPとかロードバランサーの話題なんて反則だあああ

2008-02-27

Joel On Software私訳

訳してみた。あらためて、和訳はものすごく時間を要する作業だということがわかった。もうしないと思う。

注意:以下は意訳、適当訳、稚拙訳であり、誤訳を多々含んでいることは確実であり、Joel氏が本当に以下のように述べているとは限りません。

なぜMicrosoft Officeファイルフォーマットはこんなにもややこしいのか (そしてその対処法を幾つか)

Tuesday, February 19, 2008

先週、MicrosoftOfficeバイナリフォーマットを公開したが、このフォーマットは殆ど正気でないように見える。Excel 97-2003ファイルフォーマットは349ページのPDFファイルだ。でも待って、それで全部じゃない。このドキュメントには次の面白いコメントが書いてある。

それぞれのExcelワークブックは1つのcompound fileに収められている

つまり、Excel 97-2003ファイルはOLE coumpound documentで、それは結局、1つのファイル内にあるファイルシステムである。これは、理解するのにあと9ページはスペックを読まなくちゃならないぐらいには十分に複雑だ。そしてこれらの「スペック」は、普通我々が考えるようなスペックというよりは、Cデータ構造みたいに見える。これ全体が階層的ファイルシステムなのだ。

もしあなたが週末を、Wordドキュメントブログインポートしたり、あなたの個人的な財務データからExcelフォーマットスプレッドシートを生成するような気の利いたコードを書くのに使おうと思ってこれらのドキュメントを読み始めたなら、このスペックのややこしさと長さがそんな気をあっという間に失せさせるだろう。普通プログラマはこのOfficeバイナリファイルフォーマットについて次のような結論を下す:

この4つ全てについて、きみは間違っている。ちょっとだけ掘り下げて、これらのファイルフォーマットがどうしてこんなに信じがたいくらいに複雑なのか、なぜMicrosoftの悪いプログラミングを反映しているのではないのか、そしてそれを回避するためにあなたに何ができるか、を明らかにしよう。

理解すべき最初のことは、これらのバイナリファイルフォーマットはちょっと違ったデザインゴールを持って設計されたということだ。たとえばHTMLとは。

これらはすごく古いコンピュータで速く処理できるようにデザインされた。Excel for Windowsの初期のバージョンでは、1MBのRAM、20MHz動作の80386が Excelを快適に走らせることができるための妥当なものだった。このファイルフォーマット内には、ファイルを素早く開いたり閉じたりするための最適化が沢山仕込まれている:

これはライブラリを使うことを想定して設計されている。もしあなたがバイナリインポートするものを1から書き上げたいと思ったら、Windows Metafile Format (何か図を描く場合) や OLE Counpound Storage みたいなものをサポートしなくてはいけなくなる。もしあなたが Windows上でやるのなら、そうしたことをたいしたことのない作業にするためのライブラリサポート存在する... そういったフィーチャーを使うことは(元々)マイクロソフトチームのためのショートカットだった。でもあなたが全部を自分でスクラッチから書くなら、全部の作業を自分自身でやらなくてはいけない。

オフィスはcompound documentsに対して広範囲のサポートを持っている。例えば、スプレッドシートWord文書に埋め込んだりできる。完璧Wordファイルフォーマットのparserは、同じように、埋め込まれたスプレッドシートで何かインテリジェントなことが出来るべきだろう。

それは相互協調性(interoperability)を意識してデザインされてはいない。仮定されていたのは、WordファイルフォーマットWordからのみ読み書きされなくてはいけない、ということで、それは当時においては十分に合理的なものだった。これは、Wordチームのプログラマファイルフォーマットをどう変更するかについて決定を行う場合にはいつでも、彼らが気にするのは (a)何が高速か (b)Wordコードベースにおいて最小の行数になるのは何か、だったことを意味する。SGMLHTML-interchangeableといった標準ファイルフォーマットのようなアイデアは、最初にインターネットドキュメントの相互交換を実現するまで現実のものにはならなかった。それはOfficeバイナリフォーマットが最初に考案されてから10年後のことだったのだ。ドキュメントを交換するのにインポーターエクスポーターを使うことができるという仮定が常にあった。実際Wordは簡便な交換のために設計されたRTFと呼ばれるフォーマットを持っており、そのフォーマットは殆ど最初のころからあり、今も100%サポートされている。

それはアプリケーションの全ての複雑さを反映していなくてはいけない。 全部のチェックボックス、全部のフォーマッティングオプション、そして全部の、Microsoft Officeのフィーチャーは、ファイルフォーマットのどこかで叙述されていなくてはいけない。Wordパラグラフメニューにある、"Keep With Next" と呼ばれるチェックボックス、これはパラグラフを、その後ろのパラグラフと同じページに置くのに必要な場合は、次のページに移動させるもの(?)だが、これもファイルフォーマットの中に無くてはいけない。そしてこれはつまり、あなたがWordドキュメントを正しく読み込める完璧Wordクローンを実装したいなら、そういったフィーチャーを実装しなくてはいけないということだ。Wordドキュメントをロードする競争力のあるワードプロセッサを作っているのなら、ファイルフォーマットからそのビットをロードするコードを書くのには1分しかかからないかもしれないが、ページのレイアウトアルゴリズムをそれに対応させるのに何週間もかかるかもしれない。もしあなたがそうしない場合、カスタマーがあなたのクローンWordファイルを読み込んだら、全部のページがぐちゃぐちゃになってしまうだろう。

それはアプリケーション歴史を反映していなくてはいけない。 このファイルフォーマットに見られる多くの複雑さは、古く、複雑で、愛されず、めったに使われないフィーチャーを反映している。それらはファイルフォーマットのなかに後方互換性のためにまだあり、そしてMicrosoftにとってその辺りのコードを残しておくことには何らコストはかからない。しかしあなたがこれらのファイルフォーマットをparseおよびwriteする一貫した完全な仕事をしたいと思うなら、Microsoftインターンが15年前にやったのと同じことを全て、またやらなくてはいけない。要点は、何千人年の仕事が今のWordExcelには費やされてきたのであり、これらのアプリケーション完璧クローンを作りたいと本当に欲するなら、あなたは何千人年を費やさなくてはならないことになる、ということだ。ファイルフォーマットは単に、アプリケーションサポートする全てのフィーチャーの簡潔なサマリーなのだ。

手始めに、小さな例を一つ、深く見てみよう。Excelのワークシートは色々なタイプのBIFFレコードの集まったものだ。私はスペックの一番最初のBIFFを見てみたい。1904と呼ばれるレコードだ。

Excelファイルフォーマット仕様のこのレコードについての記述は非常に曖昧なものだ。そこでは単に、1904レコードが「1904日付システムが使われているかどうか」を示すレコードだ、と述べているだけだ。ああ、使えない仕様書の典型的な一例だ。あなたがExcelファイルフォーマットで何かしている開発者で、そしてファイルフォーマット仕様にこう書いてあるのを見つけたなら、あなたがMiocrosoftは何かを隠しているのだと結論付けたとしても無理はない。この情報の断片は十分な情報をあなたに与えはしない。あなたには幾ばくか外部の情報が必要で、私は今ここで、それを提供しよう。Excelワークシートには、2種類ある。日付のエポックが1900/1/1のもの(これには、Lotus 1-2-3 との互換性のために故意に入れられた閏年に関するバグがあるが、ここでそれについて述べるのは退屈すぎる)、および、1904/1/1のものだ。Excelは両方をサポートしているが、それはExcelの最初のバージョンMac版であり、それは単に簡単だったという理由でOSエポックを使っていて、しかしWindows版のExcel1-2-3ファイルインポートできなくてはならず、そしてそれは1900/1/1をエポックとして採用していたからだ。あなたが涙ぐむのも無理はない。歴史のどの時点においても、プログラマが正しいことをしなかった、という時はないのだが、しかし現実にあなたが手にしているものはこれなのだ。

1900と1904のファイルタイプは両方とも世の中には広く存在しており、それは通常、ファイルWindowsMacのどちらで作られたかによる。一方のタイプから他方のタイプへ黙って変換するのはIntegrity的に問題があるので、Excelファイルタイプを変換することをしない。Excelファイルをparseするためには、あなたは両方を扱わなくてはならない。それはファイルからこのbitをロードするだけの問題ではなく、あなたが日付表示と両方のエポックを扱うparsingのコードまで書き直さなくてはいけないということを意味する。実装には何日かかかるだろうと私は思う。

実際、あなたがExcelクローンの作業をするなら、日付の扱いについて、あらゆる種類の微妙ディティール発見することになるだろう。Excelは日付の値をいつ変換するのか? 表示の整形はどうやっているのか? なぜ1/31は今年の January 31と翻訳され、また一方で1/50はJanuary 1st, 1950と翻訳されるのか? Excelソースコードと同じだけの量のドキュメントを書かないがぎり、振る舞いに関しての微妙ビットを全て完全に記述することはできない。

そしてこのレコードは、あなたが扱う何百もあるBIFFレコードの最初の1つに過ぎず、しかももっとも単純なものなのだ。他のレコードの殆どは、より多くのプログラマーを涙に暮れさせるぐらいには十分複雑だ。

唯一導き得る結論はこれだ。

MicrosoftMicrosoftOfficeファイルフォーマットリリースしたことは大変有用なことだが、しかしそれでOfficeファイルフォーマットインポートしたり保存したりするのが楽になるということは全く無さそうだ。それらは狂気じみて複雑で、リッチアプリケーションで、そしてあなたは人気のある20%の部分を実装して80%の人々を幸せにするというくらいのことしかできない。バイナリファイル仕様によってなされるのは、多く見積もっても、著しく複雑なシステムリバースエンジニアリングにかかる時間を何分か削減するくらいだろう。

オーケー, 私はいくつか回避法を教えると約束した。良いニュースは、殆どの良く知られたアプリケーションにとって、Officeバイナリファイルフォーマットを読み書きしようと試みることは誤った決定だということだ。あなたが真剣に考えなくてはいけない代案が2つある。Officeそのものにそれをやらせるか、書き込むのが簡単なファイルフォーマットを使うかだ。

ヘビーな仕事Officeにやらせよう。WordExcelは実に完全なオブジェクトモデルを持っており、COMオートメーションの手段が可能で、これであなたは何でもプログラムでやるようにできる。多くのシチュエーションでは、Office内のコードを再利用するほうがそれを実装しようとするよりも良い。ここにいくつか例がある。

  1. Webベースアプリケーションがあって、それが既存のWordファイルPDFフォーマットに出力するようにする必要がある場合、それを実装するにはこうする: ファイルを読み込んでからWord 2007のビルトインのPDFエクスポーターを使ってそれをPDFとして保存する、数行のWord VBAコードだ。あなたはこのコードIISで動作しているASPASP.NETコードから直接呼び出す。これでうまくいく。最初にWordを立ち上げるときは数秒かかる。2回目はCOMサブシステムによりWordはまたあなたがそれを必要としたときのためにメモリ中にキープされている。それは通常のWebベースアプリケーションにとっては十分に速い。
  2. 上と同じ。ただしあなたのWebホスティング環境Linuxだった場合。フルライセンスWordインストールされたWindows 2003サーバを買う。そしてその仕事をする小さなWebサービスを構築する。C#ASP.NETでの半日の作業だ。
  3. 上と同じ、ただしあなたがよりスケールさせたいと望む場合。ステップ2で構築した全部のボックスの前にロードバランサーを置きなさい。コードは必要ない。

この手のアプローチは、全ての種類の一般的なOfficeタイプについての、サーバ上であなたがやりたいと思うであろうアプリケーションで、うまくいくだろう。例えば:

これらのケースの全てにおいて、Officeオブジェクトインタラクティブ動作でないことを教えてやる方法があり、だから表示をアップデートするのに煩わされたり、ユーザ入力を促す必要はない。ところで、このようなやりかたでいく場合には、gotchas(?)がいくつかあり、そしてそれはMicrosoftは公式にサポートしているものではない。だからあなたがそれを始める前にはKnowledge baseの記事を読むように。

書き込むファイルにはもっとシンプルフォーマットを使いなさい。単にOfficeドキュメントプログラムで生成したいなら、殆どいつでもOfficeバイナリフォーマットよりももっと良いフォーマットWordExcelでも問題なく開くことができるようなフォーマット存在する。

いずれにせよ、全てのOfficeファイルを完全に読み書きできるような、文字通りのOffice競合製品を作ろうとする(その場合には、何千年もの作業があなたに予約される) のでない限り、Officeバイナリフォーマットの読み書きをするというのは、何であれあなたが解決しようとしている問題を解決するためのもっとも労働集約的な方法だ。

2008-02-01

WEBアプリセキュリティ対策はばっちり?

みんな、どのくらいまでセキュリティ対策してる?

俺の場合は、、、

使用するパラメータ標準入力(POST)、環境変数クエリストリング)を全てチェックして、

不正ならエラーを吐いて中止。

必要に応じてパラメータ削除エスケープ/クォート/サニタイズすればいいのかなあなんて、思ってるんだけど、

実際のところ、どこまでやればいいのか検討つかないや。

DOS攻撃にそなえて、アクセスしてきたIPアドレスは常に解析して、動的にアクセス拒否する必要があるのかとか、

アクセス集中にそなえて動的コンテンツキャッシュするだの、サーバクラスタリングだの、ロードバランサー設置とか、

バックアップは何分おきにやるのかとか、

午前三時にメンテナンスのために作業するのかとか、

ポテトチップスを食べた手でキーボード触るなとか、

地震地帯を避けつつ、法律問題を回避できる国で、税金エネルギーの安い土地にサーバルームを作って、

サーバを鎖で縛って、電磁波遮断して、部屋にかぎ掛けて、クーラー効かせて、元特殊部隊の人をガードマンに雇って、

最終的にはサーバ核シェルターに入れて、あらゆる攻撃から守らなくちゃいけないのかなあ。

ああ、憂鬱だ。

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