たった3つの記事のアクセス数ってどんなもん???
GoogleAnalyticsで解析してみた
ブログをやったこと無い人って一体どのくらいの記事を書くとどのくらいのアクセス数があるか疑問に思いますよね~。
かくいう私もこのブログが初めてなので、twitterやfacebookでPR無し!どこかにリンク貼ること無し!でどれくらいアクセス数があるものか見てみました。
期間は5月28日(土)~6月3日(金)の約1週間。ちなみにこのブログを作ったのも5月28日(土)です。
では、はいドン!
びっくり!微妙にアクセスされている。
ぐふふ、これはしっかりとブログをPRして広告貼ってアフェリエイトで稼げば、すぐにがっつり副収入が( *´艸`)
って、あま~い!!!
不二家のケーキどころか、同僚の女性にお菓子をもらったから自分に気があるんじゃないかと期待してしまっているくらい、あまい!!!たいてい、女性にその気は無いので勘違いしないように!
アクセスにはスパムがいっぱい
初心者ながらアクセス数を解析してみよう!トップページ下側にはアクセス元の各言語が表示されている。
おやおや?!(not set)って、どこの人?
ちょっとネットで調べると以下のことが書いてある。
(not set)・・・GoogleAnalyticsで分からなかった情報
なるほど、腐ってもシステム屋さんの私はピンときました!
これはスパム的なウィルス的な人間ではない人のアクセスだなと!
そこで調べるとGoogleAnalyticsには以下のようなチェックボックスがあるじゃないですか。
「アナリティクス設定」⇒「ビュー設定」
「ボットのフィルタリング」をチェックして、適用
よし!これで人間じゃない人は外れたはず!!!
変わんねぇ~!!!期待はずれ( ;∀;)
これは「検索エンジンのクローラーやその他ボットからのアクセスをフィルタリングする機能」とあるので、今回のとは違うらしい。。。
じゃあと、またまたネットで調べて、(not set)を直接外せば良いということに!
ちなみに(not set)自体のアクセスを解析してみると
日本がいねぇ~
セッション時間がねぇ~
参照元がスパムっぽい~!!!
はい、アクセス解析から不要です!
フィルタリングで外しましょう。
「アナリティクス設定」⇒「すべてのフィルタ」
「フィルタ名」に分かりやすい名前、
「カスタム」⇒「除外」
「フィルタパターン」に「not set」
「ビューにフィルタを適用」で対象にしたいビューを追加して、「保存」。
気をつけなきゃいけないのはこれでビューに反映されるわけではなく、
ここからアクセスから除外されていくので来週1週間を見たら外された内容で確認できるようになるので注意です!
まとめ
というわけで、アクセス数の解析は来週に持ち越しにしたいと思います。
単純に考えれば56セッション中に30セッションはスパムだったので、まあ感覚的に10人くらいは見に来てくれたのかなと。
今回の言語設定の(not set)以外もスパムはあると思うので、これからも精査していきたいと思います。
間違っている情報もあるかと思いますので、気づいた方はご指摘頂けますと幸いですm(_ _)m
ってことで今日はここまで~
ハイパーコンバージドインフラストラクチャって言いづらくない?
ハイパーコンバージドインフラストラクチャって何?
この前、「ハイパーコンバージドインフラストラクチャ」のセミナーに行ってきました。
聞いたこと無い人には???って話だと思うけど、大丈夫です。
自分も数日前まで???だったので(@_@)
ネットで調べるといくらでも説明が出てくるので、別にこのブログで読む必要性は無いと思うのですが、いまいち分かりづらい説明が多いので専門用語抜きで説明したいと思います。
一言で言うと
「Googleのようなインフラ基盤をうちのデータセンターでも使えちゃうよ♪」
って感じです。つ、伝わるかな(;^_^A
ポイントはローカルストレージのスケールアウト
インフラ技術者の人は経験があると思いますが、
ストレージが5年程度で保守切れを迎えて新しいストレージに交換する作業をやると思います。
そうすると・・・
アプリ担当者とダウンタイム調整したり、
移行作業で深夜出社したり、
移行後に障害出したり、
偉い人に土下座したり、
泣きながら帰ったり、
海岸でたそがれてみたり・・・。
こんなことは一切不要になるんです!!!
だって、Googleのシステムでダウンタイム調整されたことがありますか???
無いでしょ~。
それもこれも各サーバーのローカルストレージが論理的に1個のストレージで認識し、1台が壊れても他のサーバのストレージのデータで補完するのでシステムが止まったりしないんです。これをGoogleは何百万台、何千万台でやっていると思いますが、このシステムの場合、最低3台からそれが可能になるんです。
なのでサーバーが壊れたとしてもすぐに対応しなくても良く、壊れた順に新しいサーバーに入れ替えていけば良いので保守切れを気にしなくても問題ナッシングなのです!
更に容量が足りなければサーバを追加すれば容量アップ、スケールアップなので容量の心配からも解消!
ちっちゃいGoogleインフラ基盤の出来上がりですね♪
それ以外にすごいところって?
色々とあると思いますが、箇条書きにすると
- 汎用的なx86サーバなので安価。※でも高かったけどね。。。
- ローカルストレージのスケールアウトは全てソフトウェア処理。
- イーサネットスイッチのLAN線さすだけ。ストレージスイッチ不要。
- サーバーラックの圧縮率が5ラック⇒ハーフラックの実績あり。
てなてな感じですかね。
すごい偏った説明なので、疑問点はネットで調べてみて。
でも今後流行りそうなので、次世代基幹システムには取り入れようかな。
ってことで今日はここまで~。
Amazonってすごいのね。
AWSってサービスがいっぱい
次世代基幹システムを検討しようと思ったものの、どっから取り掛かったら良いものか分からないので、とりあえずクラウドの雄「Amazon」を調べてみた。一般的にはAWSかな?
ちなみにホームページにあったサービスは以下。(カテゴリをまたいだ重複あり)
<コンピューティング>
Amazon EC2:クラウド内の仮想サーバー
Amazon EC2 Container Registry:Docker イメージの保存と取得
Amazon EC2 Container Service:Docker コンテナを実行および管理
AWS Elastic Beanstalk:ウェブアプリを実行および管理
AWS Lambda :イベント発生時にコードを実行
Auto Scaling
Elastic Load Balancing
Amazon VPC:独立したクラウドリソース
<ストレージとコンテンツ配信>
Amazon S3:クラウド内のスケーラブルなストレージ
Amazon CloudFront :グローバルなコンテンツ配信ネットワーク
Amazon EBS:EC2 ブロックストレージボリューム
Amazon Elastic File System:EC2 用フルマネージド型ファイルシステム
Amazon Glacier:クラウド内の低コストなアーカイブ向けストレージ
AWS Import/Export Snowball:大容量データの転送
AWS Storage Gateway:ハイブリッドストレージの統合
<データベース>
Amazon RDS:Amazon Aurora、MySQL、PostgresSQL、Oracle、SQL Server および MariaDB のマネージド型リレーショナルデータベースサービス
AWS Database Migration Service:最小限のダウンタイムでデータベースを移行
Amazon DynamoDB:マネージド NoSQL データベース
Amazon ElastiCache:メモリ内キャッシュサービス
Amazon Redshift:高速、シンプル、費用対効果の高いデータウェアハウス
<ネットワーク>
Amazon VPC:独立したクラウドリソース
AWS Direct Connect :AWS への専用線接続
Elastic Load Balancing
Amazon Route 53:スケーラブルなドメインネームシステム(DNS)
<セキュリティと ID>
AWS Identity and Access Management (IAM):ユーザーアクセスと暗号化キーの管理
AWS Certificate Manager:SSL/TLS の証明書のプロビジョニング、管理およびデプロイ
AWS CloudHSM:法令遵守のためのハードウェアベースキーストレージ
AWS Directory Service:Active Directory のホスティングと管理
Amazon Inspector:アプリケーションのセキュリティの分析
AWS Key Management Service:マネージド型の暗号化キー作成と管理
AWS WAF:悪意のあるウェブトラフィックのフィルター
<分析>
Amazon EMR:ホスト型 Hadoop フレームワーク
AWS Data Pipeline:定期的なデータ駆動型ワークフローに対するオーケストレーションサービス
Amazon Elasticsearch Service:Elasticsearch クラスターを実行し、スケールする
Amazon Kinesis:リアルタイムストリーミングデータとの連携
Amazon Machine Learning:デベロッパー向け機械学習
Amazon QuickSight:高速ビジネスインテリジェンスサービス
Amazon Redshift:高速、シンプル、費用対効果の高いデータウェアハウス
<アプリケーションサービス>
Amazon API Gateway:API を構築、発行、および管理する
Amazon AppStream:低レイテンシーのアプリケーションストリーミング
Amazon CloudSearch:マネージド型検索サービス
Amazon Elastic Transcoder:スケーラブルで使いやすいメディアトランスコーディング
API ベースの支払いサービス
Amazon SES:E メール送受信サービス
Amazon SNS:プッシュ通知サービス
Amazon SQS:メッセージキューサービス
Amazon SWF:アプリケーションコンポーネントを連携させるワークフローサービス
<開発者用ツール>
AWS CodeCommit:プライベート Git リポジトリでのコードの保存
AWS CodeDeploy:コードデプロイの自動化
AWS CodePipeline:継続的デリバリーを使用したソフトウェアのリリース
AWS コマンドラインツール:AWS サービスを管理するための統合ツール
<管理ツール>
Amazon CloudWatch:リソースとアプリケーションのモニタリング
AWS CloudFormation:テンプレートを使ったリソースの作成と管理
AWS CloudTrail:ユーザーアクティビティと API 使用状況の追跡
AWS コマンドラインツール:AWS サービスを管理するための統合ツール
AWS Config:リソースのインベントリと変更の追跡
AWS マネジメントコンソール:ウェブベースのユーザーインターフェイス
AWS OpsWorks:Chef を使った操作の自動化
AWS Service Catalog:標準化された製品の作成と使用
AWS Application Discovery Service:データセンターアプリケーションとその依存関係の検出
Trusted Advisor:パフォーマンスとセキュリティの最適化
<モバイルサービス>
AWS Mobile Hub:モバイルアプリの構築、テスト、モニタリング
Amazon API Gateway:API を構築し、デプロイし、管理する
Amazon Cognito:ユーザー ID およびアプリケーションデータの同期
AWS Device Farm:AWS クラウド内の実際のデバイスを使った Android、iOS およびウェブアプリケーションのテスト
Amazon Mobile Analytics:アプリ分析の収集、表示、エクスポート
AWS Mobile SDK:高品質のモバイルアプリを迅速かつ簡単に構築
Amazon SNS :プッシュ通知サービス
<エンタープライズアプリケーション>
Amazon WorkSpaces:クラウド内の仮想デスクトップ
Amazon WorkDocs:安全なエンタープライズドキュメントのストレージおよび共有
Amazon WorkMail:セキュリティに優れた E メールとカレンダー
<ゲーム開発>
Amazon Lumberyard:AWS や Twitch と統合された完全なソースを利用できる、無料のクロスプラットフォーム 3D ゲームエンジンです。
・・・多いっちゅうねん!!!
コピーするだけなのに、めっちゃ手がつかれた。。。
どんだけ~☝
AWSで良く使うもの
良く分からないので簡単に色分け。
赤字:単純に企業内ネットワークとしてサーバー構築するのに必要。
青字:もう一歩進んで、大量アクセスに耐えたり、リアルタイムデータやりとりしたり、かっちょよく分析基盤にしたりに必要。
色なし:マニア向け。
ストレージの種類と用途
サーバー作るのは「EC2」使えば良いって分かるけど、ストレージは種類あって難しいね~。っていうことでちょっと調べたら、以下。
S3:オンラインストレージ。インターネットから直接ファイル置ける。EC2のローカルストレージとして使用不可。すごく安い。約4円~/1ギガ1ヶ月。
EBS:外付けHDD。インターネットから直接ファイル置けるか不明。EC2のローカルストレージとして使用可能。EC2:ストレージの関係は1:1。それなりに安い。約10円~/1ギガ1ヶ月。
EFS:NAS。インターネットから直接ファイル置けない。EC2のローカルストレージ(1:N)として使用可能。EC2:ストレージの関係はN:1。ちょっと高い。約30円~/1ギガ1ヶ月。
※初心者調べなので、間違ってたらごめんね(∀`*ゞ)テヘッ
今年のAWSのクラウドカンファレンス
今更だけど、6月1日~6月3日まで「AWS SUMMIT TOKYO 2016」がやるんだね~。もう申し込みいっぱいだし、仕事のスケジュール上、行けないけど。。。
ってことで今日はここまで~。
次世代基幹システムって響きはかっこいいよね。
運命の日
2016年4月・・・。
異動となった先での上司との会話。
上司「alps君。もううちの社内基幹システムも5年経ったね~」
alps「そうですね~」
上司「そろそろ基幹システムのリプレイス考えないとね~」
alps「そうですね~」
上司「今の世の中ならすごい次世代基幹システムが考えられるんじゃない」
alps「そうですね~」
上司「よろしくね(^◇^)」
alps「そうで・・・(´・ω・`)」
あっ、俺が考えるんですね。
他人事だと思って聞いてたんですけど、俺なんですね。。。
う~ん、プロジェクトが始まったら精神が破壊されそうな嫌な予感が・・・。
まあ、構想考えるところは楽しそうな仕事なんで、1年かけてブログにメモしながら考えていこうかな~。。。
ってことでこのブログです。
構想に今年いっぱい使って良いそうなので、ゆるゆるやっていこうかなって思います。
よろしくお願い致しますm(_ _)m