【OpenStackチャレンジ】 第5回 Ceilometerについて知ろう!

2016.1.13


メータリングを司るコンポーネント「Ceilometer」

dev.jpg

以前、数あるOpenStackのコンポーネントを纏めてご紹介しましたが、その中の1つにCeilometerというものがあったのを覚えていますでしょうか?

名称の由来は"雲高計"。ユーザへの課金を想定し、OpenStack上のリソース消費を計測/集計する機能を持ちます。

今後このCeilometerにもチャレンジしていこうと思うのですが、まずは敵を知るべし(?)という事で、今回はOpenStackプロジェクトが公開している公式ドキュメントを和訳の上、概要/アーキテクチャを詳細に解説します!(きちんとした和訳もまだ存在していない様なので)

アカデミックな内容かつ長文となりますが、どうぞお付き合い下さい。

Ceilometerを理解しよう(1) ~概要

 

■Ceilometerプロジェクトのビジョンとは

OpenStackのCeilometerプロジェクトでは、既存~将来サポートされるであろう全てのOpenStack主要コンポーネントにおいて、顧客請求に必要なあらゆるメータリングを可能にする、独自システムの提供を目指しています。

プロジェクトの目標/ビジョンをもう少し具体的にすると、以下の様に纏められます。
・CPUやネットワークの費用測定データを効率的に収集。
・直接/代替のコンポーネントから、開発ツールとメータリングシステムを統合化。
・各データは、既存サービスから送信されたnotificationsの監視か、インフラへのpollingにより収集。
・収集データの種類を設定可能にし、開発者のオペレーション要求を満たす。
・ユーザはREST APIを介し、メータリングシステムが収集したデータを視覚確認。
・メータリングメッセージは(料金の)確証になり、ユーザはこれを拒否できない。

■目的

「OpenStackに関して必要となる、全ての情報を収集可能なインフラをつくる」というシンプルな目標の元、2012年にCeilometerプロジェクトは開始されました。開発においては、評価エンジンを使用し、各イベントを請求可能な状態(=メータリング)に変換できる様設計されているのが、Ceilometerの特徴といえます。

プロジェクト活動の旺盛に伴いメータリングの母数が増加する中で、OpenStackコミュニティはCeilometerが「目的に関わらず、情報を収集するための標準的手法になる」という、新たな目的を持ちうる事に気付きました。例えばCeilometerは、メータリングのバックエンドに加え(又は並行して)、監視・デバッグ・グラフツールに関する情報を公開しており、この取組については"multi-publisher"と呼ばれています。

■Ceilometerの役割 "メータリング"

請求が発生するプロセスについては、電気通信業界で一般的に理解されている様な以下3ステップに分類する事ができます。

ステップ1.測定(Metering)
ステップ2.評価(Rating)
ステップ3.請求(Billing)

Ceilometerが掲げてきた本来的な目的は、ステップ1に厳格に限定されています。プロジェクトの規模を鑑みた際に、プライベートからパブリックなクラウドに至るまで、万人のニーズに応えるソリューションを提供する事が難しいという判断から、評価(Rating)および請求(Billing)については対象外とする選択肢が当初から採られてきました。

つまり、請求関連のニーズの元、Ceilometerを参照するのは適当な手段といえますが、実はその目的はCeilometerのみで果たされるわけではないのです。

Ceilometerが特定のOpenStackデプロイメント上に配置された後も、顧客請求までのプロセスは複数残っています。その内、例えば所有する評価エンジンに必要情報を抽出するためのCeilometer APIへのright queries確認は、最初に対応すべきタスクの1つといえるでしょう。 

Ceilometerを理解しよう(2) ~システムアーキテクチャ

 

■ハイレベルなアーキテクチャ

ggggg.png

Ceilometerの論理アーキテクチャについて、包括的にご紹介します。

Ceilometerの各サービスは水平的(横並び)なスケールで設計されており、新たなノードは想定されるロード量に基いて追加されます。Ceilometerには5つのコアサービスが存在しており、data agentはデータ収集から独立して動作する様設計される一方、ソリューションとして動作する様にも設計されています。

polling agent:OpenStackの各サービスおよびメータリングを構築するために設計されたデーモン。
notification agent:メッセージキュー上のnotificationsをリッスンし、それらをイベントおよびsampleに変化させ、パイプラインアクションを適用するために設計されたデーモン。
collector(※3):notification/polling agentにより生成されたイベントおよびメータリングデータをgathering/記録するために設計されたデーモン。
API:collectorサービスが記録したデータへ問合せ/閲覧をするサービス。

Ceilometerがより多くのデータをキャプチャできる様進化を続ける中、データストレージが最適化される必要性が生じました。さらにストレージおよび問合せ最適化のためにデータベースが時系列順にデータキャプチャリングできる様、既存のメータリングデータベースのインターフェース置き換えを目的として開発されたのがGnocchi(resource metering as a service)です。

ceilo-gnocchi-arch.png

上図は、CeilometerとGnocchiが連携した際の包括的な論理アーキテクチャです。

(※1)OPCEL認定試験の出題では「ceilometer-alarm-evaluator」と表記。各アラームの状態が変更となった際でも引き続き検出できる様、アラームを定期的に診断します。
(※2)OPCEL認定試験の出題では「ceilometer-alarm-notifier」と表記。アラームが発した際にceilometer-alarm-evaluatorが送信するnotificationsを受け取り、関連するアクションを実行します。
(※3)OPCEL認定試験の出題では「ceilometer-collector」と表記。

 

■データのgathering

~データはどの様にして収集されるのか?~

1-agents.png

上図では、collecor/agentがどの様にして複数ソースからデータをgatheringしているかを表現しています。

理想的には、搭載したい各(全ての)プロジェクトが、Osloバス上で関心となりえるイベントを送信しているべきでしょう。ただ残念な事に、全てのプロジェクトがこの通りに実装されているわけではありませんし、時にOpenStackが定義しているバスが参照しない他ツールを搭載する必要性も生じるでしょう。そんな中Ceilometerプロジェクトでは、データ収集について2つの方法を設けています。

  1. Bus listner agent:notificationバス上でイベントを生成し、それらをCeilometer-sampleへと変換します。データ収集において推奨される方法といえるでしょう。もしあなたがOpenStack関連のプロジェクトに従事し、Osloライブラリを使用しているなら、当該プロジェクトに迅速に搭載できる様、メンバーに相談をしてみて下さい。

  2. Polling agents(※4):こちらはあまり推奨されませんが、一定間隔で情報をgatheringをするためにAPIないし別ツールに対してpollingする方法です。notificationsを消費しつつ同様のデータを収集するオプションの場所を考慮すると、APIサービス上で課されるロード量の観点からpollingによるアプローチは適当とはいえません。

方法1については、notificationへのメッセージキューを監視するCeilometer-notification-agentによりサポートされています。polling agentはローカルハイパバイザーへのpolling、あるいはリモートAPI(サービスにより明らかとなったパブリックREST API、またはホストレベルのSNMP/IPMIデーモン)のいずれかにより設定されます。

(※4)OPCEL認定試験の出題では「ceilometer-polling」と表記。 

 

~notification agent:データのリッスン~

2-1-collection-notification.png

notification agent(※5)は、サービスからのメッセージを収集します。

システムの中心はnotificationデーモン(agent-notification)であり、Nova、Glance、Cinder、Neutron、Swift、Keystone、Heatといった様な他のOpenStackコンポーネントから提供されるデータのメッセージバスを、Ceilometerの内部疎通と同じ様に監視します。

notificationデーモンはネームスペースceilometer.notificationにより、1つ以上のリスナープラグインをロードします。各プラグインはあらゆるトピックのリッスンが可能ですが、デフォルトではnotification.infoをリッスンする様設定されています。リスナーは定義されたトピックからメッセージを取り出してイベントおよびsampleの内部へと進むために、適切なプラグイン(エンドポイント)に再分配します。

Sample-Orientedプラグインでは、関心のあるイベントタイプのリスト化や、それに応じたプロセスメッセージのコールバックを提供しています。コールバックの登録名は、notificationデーモンのパイプラインを用いてコールバックを使用可/不可とするために使用されます。

到着したメッセージは、コールバックに向けて通過する前段階で、それらのイベントタイプ値に基いてフィルターがかけられるため、プラグインは自身が関心のあるイベントのみを受け取ることになります。例えば、ceilometer.compute.notifications配下のcompute.instance.create.endイベントに問い合わせるコールバックは、それらのnotificationイベントをnotification.infoトピックを用いてnova exchange上で呼び出す事になります。イベントマッチングもまた、compute.instance等のワイルドカードを用いて動作します。

同様に、予め有効設定にした際は、他サービスにより宣言されたevent_typeに基いて、フィルター可能なイベント内に対してnotificationがコンバートされます。

(※5)OPCEL認定試験の出題では「ceilometer-agent-notification」と表記。

 

~polling agent:データの問合せ~

2-2-collection-poll.png

コンピュートリソースへのpollingはcompute-agent(※6)が問合せ、(ハイパバイザーとの疎通がより効率的な)コンピュートノード上で動作しています。一方でcomputeリソース以外(Volume, Network, Image, Object Strage)へのサービスAPIを介したpollingについては、central-agent(※7)が問合せ、クラウドコントローラ上で動作します。

single agentは、両方の役割をオールインワンのデプロイメントで実現します。反対にsingle agentにおける複数インターフェースについては、作業負荷が共有される場合に展開されます。polling agentデーモンは、ceilometer.poll.computeおよび(または)ceilometer.poll.centralネームスペースにより1つ以上のpollsterプラグインを動作させるために設定されています。

agentはsampleオブジェクトのインスタンスに対し定期的にpollsterを問合せ、pollingの頻度はパイプライン設定によって管理されます。詳細についてはこちらをご参照下さい。agentのフレームワークはその後、sampleをパイプラインに向けて通過させます。

留意事項として、ceilometer.conf内にはshuffle_time_before_polling_tackと呼ばれるオプションコンフィグが存在します。0以上の数値を設定する事で、pollingタスクを開始するためのagentがシャッフルされ、novaないし他コンポーネントが短期間で多くのリクエスト送信を避けるための調整を行い、このコンフィグが有効となります。加えて、ceilometer.conf内でbatch_polled_samplesをFalseに設定することで、sampleの遅延を最小限に留めるオプションも用意されています。

(※6)OPCEL認定試験の出題では「ceilometer-agent-compute」と表記。
(※7)OPCEL認定試験の出題では「ceilometer-agent-central」と表記。

■データの処理

~パイプラインマネージャー~

3-Pipeline.png

Ceilometerのパイプラインを構成するコンポーネント群です。

Ceilometerでは、agentによりデータのgathering/操作を行い、複数のパイプラインを介して多様なコンビネーションで発行します。この機能はnotification agentにより操作されています。

 

~データの変換~

4-Transformer.png

シングルCPU内におけるvCPUの時間消費sampleの集合例です。pollingおよびnotifications agentからgatheringされる膨大なデータは、過去~現在の文脈によって結合され、より大量のデータに派生します。Ceilometerはパイプライン内で複数のデータに用いるための、多様な変換機能を提供しています。

 

~データの発行~

5-multi-publish.png

上図では、sampleがいかにして複数の到達先に発行されるか表現しています。現在の所、処理を経たデータは異なる手段によって発行されています。

notifier:collectorや外部システムが消費するメッセージキューにsampleを推し進めるnotificationベースのパブリッシャーです。
udp:UDPパケットでsampleを発行します。
Kafka:Kafkaをサポートするシステムにより消費されるKafkaメッセージ・キューに対し、データを発行します。

 

■データの保存

~collectorサービス~

collectorデーモンはnotification/polling agentによりキャプチャされた処理イベントおよびメータリングデータをgatheringします。加えて、流入してきたデータの認証を実施し、(署名が有効である場合は)データベース、ファイル、httpといったターゲットに向けてメッセージを作成します。

 

 

~サポートされているデータベース~

6-storagemodel.png

Ceilometerのストレージモデルに関する概要です。

多様なデータベースのバックエンドを使用可能とするため、プロジェクト開始当時からプラグインモデルが導入されてきました。サポートされているバックエンドの詳細については、コチラにて詳細に記述してあります。

JunoおよびKiloのリリースサイクルでは、Ceilometerのデータベースはアラーム、イベント、メータリングという様に3種類の異なる接続に分類されます。これにより開発者は、シングルデータベースにデータを保管し続け、また目的に合わせてデータを自身のデータベース内に分割する事が可能となります。例えばNoSQLバックエンドでイベントの保管やデータメータリングを実行しつつ、SQLバックエンドでアラームの保存をする事も可能です。

留意事項:プロジェクトとしては、DBのスキームを変更しないという保証はできません。よって、直接問い合わせるのではなく、APIを通してデータベースにアクセスする事を強く推奨します。

 

■データへのアクセス

~APIサービス~

サポートされるデータベースに対してpolling/notification agentから収集されたデータが保存される場合、これらデータベースのスキームは時間の経過と共に発展します。従って、プロジェクトではREST APIを提供し、アンダーレイのデータベースに直接アクセスするより、ceilometer API(※8)を通して収集されたデータにアクセスすることを推奨しています。

あなたがデータにアクセスする際の然るべき手法がまだAPIでサポートされていなければ、フィードバックと共にご連絡下さい。プロジェクトでceilometer APIを改良します。

(※8)OPCEL認定試験の出題ではceilometer-apiと表記。

2-accessmodel.png

上図では、Ceilometerにより保管されたデータへのアクセスを表現しています。

CeilometerはOpenStackの一部ですが、OpenStackが定義している"users"や"tenants"に縛られるものではありません。各sampleの"source"フィールドはsampleと関連付くユーザやテナントを定義している情報源を参照しています。

開発者は設定ファイルを通じてカスタムソースを定義でき、それらソースから新しいメータリングのためのsampleを収集するべくagentを作成します。つまり、PaaSやSaaSレイヤの様に、OpenStack上で動作しているアプリケーションに対するデータ収集や、クラウド全体をメータリングするために同じツールを使用する事が可能となります。

おわりに

OpenStackに慣れない方にとっては、ややこしい解説が続いてしまいましたが、これもOpenStackエンジニアを目指す上では避けて通れない道。分からない単語は調べつつ、ぜひ読み進めて頂きたいです。

今後はCeilometerのインストールと実環境での動作を扱い、これまでの解説をより具体的にイメージして頂ける様なコンテンツを作成できればと思います!

最後までお付き合いを頂き、ありがとうございました。

photo-1414170695976-59c0463bd11d.jpg



OpenStackと同じカテゴリーの記事


SDN/NFVと同じカテゴリーの記事


ceilometerと同じカテゴリーの記事


技術関連と同じカテゴリーの記事



RSS
最近のエントリー
2017.4.21
【検証自動化】第6回 AT-CLabを使ってみる
2017.4.21
【OSSチャレンジ】第4回 Elasticsearch紹介
2017.4. 7
【OSC2017 Tokyo/Spring】OpenStackを宇宙で!?
2017.3.28
【OSSチャレンジ】 第3回 Bacula紹介:後編
2017.3. 9
【OpenStackチャレンジ】 第29回 Ocata紹介編
2017.2.24
【OSSチャレンジ】 第2回 Docker紹介編
2017.2.20
【OSSチャレンジ】 第1回 Bacula紹介:前編
2017.2. 1
【体験記】最後のフロンティア!? ~ミャンマー 体験記~
2017.1.18
【データベース】pgpool-IIによるDBサーバ負荷分散
2016.12.16
【ログ解析】第2回Splunkのログ解析
2016.12. 9
LPIC304 体験記
2016.11.19
【OSC2016 Tokyo/Fall】VRとOpenStackを連携
2016.11.11
【次世代通信技術】 第1回 5G入門編
2016.10.28
【ログ解析】第1回Splunkの紹介と起動
2016.10.21
【OpenStackチャレンジ】 第28回 Stackalytics登録編
2016.10.14
【OpenStackチャレンジ】 第27回 OpenStack Newton紹介編
2016.10. 7
【検証自動化】第5回 Selenium IDEで記録したテストをJenkinsのジョブから実行する ~PC一台でブラウザテストを自動化~【後編】
2016.9.30
【OpenStackチャレンジ】 第26回 Neutron環境構築編
2016.9.23
【いまさら聞けない!エンジニアの基本シリーズ】 第6回 きれいなログにするためのLinuxお作法
2016.9.16
【OpenStackチャレンジ】 第25回 Nova環境構築編
2016.9. 9
【OpenStackチャレンジ】 第24回 Cinder環境構築編
2016.9. 2
【OpenStackチャレンジ】 第23回 OpenStackコミュニティ~翻訳編
2016.8.26
【OpenStackチャレンジ】 第22回 Glance環境構築編
2016.8.19
【検証自動化】第4回 Selenium IDEでテストケースを記録・実行する ~PC一台でブラウザテストを自動化~【前編】
2016.8. 9
【OpenStackチャレンジ】 第21回 OpenStackコミュニティ 日本語翻訳チーム参加編
2016.8. 5
【OpenStackチャレンジ】 第20回 構成管理ツール「Ansible」を用いたOpenStack上のサーバ構築
2016.7.29
【検証自動化】第3回 IT検証フォーラム2016に出展しました!
2016.7.22
【OpenStackチャレンジ】 第19回 OpenStack Upstream Training編
2016.7.15
【検証自動化】第2回 TestShell+TestCenter連携編
2016.7. 8
【OpenStackチャレンジ】 第18回 HEAT紹介編
2016.7. 4
QNAP紹介(Dockerコンテナ&OpenStack Swift連携)
2016.6.26
【いまさら聞けない!エンジニアの基本シリーズ】 第5回 GitHubを使いこなそう
2016.6.19
【OpenStackチャレンジ】 第17回 Zabbix環境構築編
2016.6.12
【検証自動化】第1回 TestShell編
2016.6. 5
【OpenStackチャレンジ】 第16回 Mirantis 「OpenStack FUEL管理」セミナー紹介編
2016.5.29
【OpenStackチャレンジ】 第15回 Swift環境構築編
2016.5.22
【OpenStackチャレンジ】 第14回 Keystone環境構築編
2016.5.15
【OpenStackチャレンジ】 第13回 Mirantis OpenStack紹介編
2016.5. 2
【OpenStackチャレンジ】 第12回DevStack~ Ironic環境構築編
2016.4.24
【OpenStackチャレンジ】 第11回 インフラエンジニア必見のOpenStackセミナーを開催しました!
2016.4.17
【OpenStackチャレンジ】 第10回 OpenStack Mitaka紹介編
2016.4.10
【Linuxを使いこなす】 CentOSのローカルリポジトリを構築しよう
2016.4. 3
【OpenStackチャレンジ】 第9回 仮想マシンが起動するコンピュートノードを指定してみよう
2016.3.29
【OpenStack チャレンジ】 第8回 ゲストマシンの性能比較をしてみました!
2016.3.19
【OSC2016】第3回 ChatOpsでOpenStackをAPIから制御する
2016.3.12
【OSC2016】第2回Let'sChat Hubot編
2016.3. 4
【OSC2016】第1回ChatOpsの構築
2016.1.31
【OpenStackチャレンジ】 第7回 DevStack~All-In-One Single Machine編
2016.1.22
【OpenStackチャレンジ】 第6回 policy.json紹介編
2016.1.13
【OpenStackチャレンジ】 第5回 Ceilometerについて知ろう!
2016.1. 8
【いまさら聞けない!エンジニアの基本シリーズ】 第4回 VMware基本動作編
2015.12.24
【1年間ありがとう!】2015年度エンジニアブログ アクセスランキング発表!
2015.12.18
【SDNチャレンジ】 第29回 Mininet編
2015.12.14
【いまさら聞けない!エンジニアの基本シリーズ】 第3回 VMwareインストール編
2015.12.10
【OpenStackチャレンジ】第4回 ConoHaでOpenStack環境を構築!
2015.12. 4
【いまさら聞けない!エンジニアの基本シリーズ】 第2回 VirtualBox基本動作編
2015.12. 4
【OpenStackチャレンジ】 第3回 OpenDaylight(Lithium)との連携に挑戦!
2015.11.27
【いまさら聞けない!エンジニアの基本シリーズ】 第1回 VirtualBoxインストール編
2015.11.20
【SDNチャレンジ】 第28回 WiresharkでOpenFlowを解析しよう!
2015.11.15
OpenStackの技術者認定資格「OPCEL認定試験」に合格しました!
2015.11. 9
「Windows Server 2003」から「Windows Server 2012 R2」への移行に不安を抱えるお客様へ
2015.11. 6
【SDNチャレンジ】 第27回 OpenMUL編
2015.10.30
【SDNチャレンジ】 第26回 ONOS-BGPルータ編
2015.10.23
【SDNチャレンジ】 第25回 ONOS GUI編 / [告知]10/24(土),25(日)にOSCに出展します!
2015.10.16
【SDNチャレンジ】 第24回 ONOSインストール編
2015.10. 9
【SDNチャレンジ】 第23回 OpenDaylightユーザ会に参加しました/Lithiumインストール編
2015.10. 2
【SDNチャレンジ】 第22回 Trema-edge編
2015.9.29
【OpenStackチャレンジ】 番外編 10/26(月)からLPI-Japanの「OPCEL認定試験」がスタートします!
2015.9.25
【SDNチャレンジ】 第21回 POX編
2015.9.18
【OpenStackチャレンジ】 第2回 コンポーネント紹介編
2015.9.11
【SDNチャレンジ】 第20回 Floodlight編
2015.9. 4
【OpenStackチャレンジ】 第1回 OpenStackインストール編
2015.9. 3
【ウェブサイトのロードテストをする】 最終回 Siege編
2015.8.28
【SDNチャレンジ】 第19回 Raspberry Piでユースケースに挑戦!
2015.8.21
【SDNチャレンジ】 第18回 OF-Patch動作編
2015.8.13
【SDNチャレンジ】 第17回 OF-Patch紹介編
2015.8. 7
Windows10をインストールしてみました!
2015.8. 4
【ウェブサイトのロードテストをする】 第3回 Tsung編
2015.7.31
【SDNチャレンジ】 第16回 Ryuコントローラインストール編
2015.7.25
【SDNチャレンジ】 第15回 Open vSwitch性能試験編
2015.7.17
【SDNチャレンジ】 第14回 Tcpreplay編
2015.7.17
RedHat OpenStack 管理者認定試験に合格しました!
2015.7.11
【SDNチャレンジ】 第13回 Vyattaコントローラ REST API編
2015.7. 3
【SDNチャレンジ】 第12回 Vyattaコントローラ動作編
2015.7. 1
【ウェブサイトのロードテストをする】 第2回 curl-loader編
2015.6.26
【SDNチャレンジ】 第11回 OpenDaylight動作編②
2015.6.19
【SDNチャレンジ】 第10回 OpenDaylight動作編①
2015.6.18
【ウェブサイトのロードテストをする】 第1回 Apache JMeter編
2015.6.12
【SDNチャレンジ】 第9回 リピーターハブとラーニングスイッチの動作比較編
2015.6. 5
【SDNチャレンジ】 第8回 Tremasharkインストール編
2015.5.25
【SDNチャレンジ】 第7回 帯域制御・ファイアウォール・パケット書換え編
2015.5.22
【SDNチャレンジ】 第6回 ラーニングスイッチ作成編
2015.5.15
【SDNチャレンジ】 第5回 Raspberry Pi2にOpen vSwitchをインストール
2015.5. 8
【SDNチャレンジ】 第4回 5/13(水)、14(木)、15(金)の展示会にて検証自動化デモを実施します!
2015.4.27
【SDNチャレンジ】 第3回 Tremaリピーターハブ編
2015.4.21
【SDNチャレンジ】 第2回 OpenFlowコントローラ作成編
2015.4.14
【SDNチャレンジ】 第1回 Tremaインストール編
2014.8.20
【注意!】8月13日のWindows Updateを適用すると起動できなくなる事例が報告されています!
2014.5.23
約6割の企業が悩んでいるのに、対策しないんですか...?
2014.1. 9
新年あけましておめでとうございます。
2013.12.24
2013年エンジニアブログ アクセスランキング発表!
2013.12.17
コミュニケーション「活性化」の第一歩
2013.10.29
なぜ儲かっているのか分からない!?
2013.10.15
「何を変えるのか、何に変えるのか、どのように変えるのか」
2013.9.17
ブラック企業にドラッカーがアドバイスするとしたら?
2013.9. 4
蟻の穴から堤も崩れる
2013.8. 6
派閥じゃなくて、理念の元に仕事をしよう!
2013.7.31
知識は使ってナンボです!
2013.7.30
御社の相互理解度はどれくらい?
2013.7. 3
何故、それが読まれたか~上半期・エンジニアブログ閲覧数ランキング~
2013.6.12
「何」を知っているかではなく、「誰」が知っているか
2013.5.28
戦後、人間尊重の信念を貫きとおした1人の経営者がいた!
2013.5.24
健康な心が、健康な会社を作る。
2013.4.26
『社長にはもうついていけません・・・』
2013.4.23
仕事と生活をバランスさせるには?
2013.4. 2
組織に必要なのは「ゆらぎ」と・・・?
2013.3.21
代表小林、バングラディシュの地に再度降り立つ
2013.3.14
色々作っちゃいました!
2013.3. 5
「心のバランスシート」に着目していますか?
2013.2. 6
Office2013発売!で、何が変わった?
2013.2. 1
「想いを語る夕べ」が新宿から30分の場所で開催可能に!
2012.12.25
エンジニアブログ番外編:決戦は「ひなたかなた」
2012.12.19
2012年エンジニアブログ&Facebook閲覧数ランキング発表!
2012.11.29
プロセス見直すのはいいけれど...大事なこと忘れてません?
2012.10.31
「仕事」と「個々の生活」の両立~ワーク・ライフ・バランス~
2012.10.26
Windows8発売!で何が起こる?
2012.10. 9
腹が減っては打ち合わせは出来ぬ?~アドック近辺ランチスポット・カフェ編~
2012.10. 2
iPhone5発売!LTE普及には切実な背景が...
2012.9.12
「だれを選ぶか」をまず決めて、その後に「何をすべきか」を決める。
2012.8.17
会社を回すのに大事な3つの感覚。
2012.8. 7
プロジェクトはたいてい失敗に終わるんです。
2012.7.19
『目の前に壁があったら、突き破るしかねえんだよ』by鬼塚
2012.7. 2
大手企業も多数協賛する「東京経営塾」の塾長とは!?
2012.6.15
メンタルヘルスケアジャパン2012報告!
2012.6. 4
御社の理念浸透力はどれくらい?!
2012.5.14
メンタルヘルスケアジャパン2012参加のお知らせ
2012.4.27
東京スカイツリーと地デジとADOC
2012.4.17
マイボトル・マイカップキャンペーン/エンジニアブログ1周年記念
2012.3.14
第1回「想いを語る夕べ」体験会レポート~伝えることの難しさ~
2012.2.29
想いを語る夕べ報告書を新聞にしちゃいました!
2012.2. 6
月刊『ニュートップリーダー』に記事掲載&"想いを語る夕べ"体験会やります!
2012.1.31
【第4回】想いを語る夕べ~フォロー編~
2012.1.23
タニタの社員食堂は"トップの想い"から生まれた!?
2012.1.13
【第3回】想いを語る夕べ~実施編~
2011.12.27
オフィスで簡単エクササイズ!
2011.12.13
【第2回】想いを語る夕べ~準備編~
2011.11.24
【第1回】想いを語る夕べ~誕生編~
2011.11.17
「責任感だけで仕事をしていた・・・。」が「自らサービスを作り上げ、喜びを感じたい!」という熱い想いに変わるまで
2011.11. 8
アドックインターナショナルはGoogleのまわし者!?
2011.10.11
あなたのその行動、誰かに監視されてませんか?
2011.9.28
たったこれだけのことで、チームに一体感が生まれる!?
2011.9.22
ADOCersがITS健康保険組合の野球大会に出場します!
2011.9.21
アドックに入社するとコンサートホールで歌えてグァムに行けるってホント?
2011.8.30
アドック社員元気の素!?
2011.8.16
電力使用制限発動!罰金は100万円!?PC電力管理ソフトのススメ
2011.8. 9
「ネットトラブル調査隊」対象エリア拡大しました!(後日談付き)
2011.8. 1
Windows7にはメールソフトが付いてない!?
2011.7.22
「社長の想いを語る夕べ」プログラムのご紹介
2011.7.12
64ビット版Windowsへの移行について
2011.7. 8
検証やテストを自動化する際に気を付けなければいけない3つの事
2011.7. 5
地デジと周波数再編とADOC
2011.6.29
アドックインターナショナルの節電対策とスーパークールビズ
2011.6.27
あるレンタカー事業会社のケース
2011.6.20
ラボルームのご紹介
2011.6.17
Interop Tokyo 2011に行ってきました!
2011.6. 7
ADOCの保守サービスと震災対応
2011.5.31
"メンタルヘルスケア・ジャパン2011"レポート
2011.5.19
「おばあちゃん家」
2011.5.11
スマートフォンは急速に普及している・・・?
2011.5. 9
ADOCの品質改善活動への取り組み事例をご紹介
2011.4.19
ADOCのお花見と節電への取り組み
2011.4. 6
復興支援のため東北へ向かっていた弊社の社員2名が戻ってきました!その2
2011.3.31
復興支援のため東北へ向かっていた弊社の社員2名が戻ってきました!
2011.3.28
弊社パートナーが被災地支援のサービス開始
2011.3.25
震災により表面化した携帯通信網の弱さ
2011.2.28
エンジニアブログスタートのお知らせ
カテゴリー
月別アーカイブ

<